Appliance User Guide
This guide walks you through deploying a ThreatDefence appliance from start to finish: download the image, boot and configure the virtual machine, enrol it with an activation code, and turn on monitoring.
You will work in two places:
SecOps Portal (Deployment → Appliances)
Central portal
Fleet overview, activation codes, capabilities, log sources, archiving and vulnerability scans, for every appliance you manage
Appliance web UI (https://<appliance-ip>:8952)
On the appliance itself
Local settings: activation, connectivity checks, NDR monitoring interfaces, network settings, OS updates and local logs
NDR stands for Network Detection and Response: analysis of a mirrored copy of your network traffic. It is one of the capabilities the appliance can run, alongside log collection, archiving and vulnerability scanning.
Deploying again? The quick reference table at the end of this page collects the logins, ports, addresses and timings in one place.
Before you start: network requirements
The appliance's management interface needs outbound access to the following destinations. If your firewall restricts outbound traffic, raise these rules before you deploy, so enrolment works first time.
Control plane (enrolment, configuration, check-in)
apl-au.secops-apps.io
apl-us.secops-apps.io
TCP 443
Platform ingest (network events and collected logs)
apl-ingest-au.secops-apps.io
apl-ingest-us.secops-apps.io
TCP 443
Container registry (monitoring service images)
hub.secops-apps.io
hub.secops-apps.io
TCP 443
Update repository (appliance software updates)
pkgs.secops-apps.io
pkgs.secops-apps.io
TCP 443
OS package mirrors (OS security updates)
archive.ubuntu.com, security.ubuntu.com
same
TCP 80
Time synchronisation
your NTP source, or the default Ubuntu NTP pool
same
UDP 123
Remote engineer access (optional, off by default, see section 12)
tps.deploydefend.io
tps.deploydefend.io
TCP 443
Use the endpoints for your region. Your activation code is tied to a region, and the appliance's built-in connectivity check (section 5) verifies every one of these after deployment, so you can confirm the rules landed correctly.
1. Download the appliance image
In the portal, go to Deployment → Appliances → Deploy and Codes and pick the image for your hypervisor:
VMware (OVA) for vSphere, ESXi or Workstation
Hyper-V (VHD)
QCOW2 for KVM, QEMU or Proxmox
Clicking a hypervisor button reveals a download link with Copy and Download buttons. Copy the link to pull the image straight onto a hypervisor host, or download it in your browser. The images are large (roughly 2.5 GB for the OVA and QCOW2, and 5.7 GB for the VHD), so allow for the download time on slower links.
If you are using a physical sensor instead of a virtual machine, no download is needed: physical sensors arrive with the software already installed. Contact support to arrange one.
2. Generate an activation code
On the same page, use Generate activation code. Enter a name (required). The name identifies the code in the list, so use the site or customer name.
You can also tick capabilities to pre-enable. The appliance deploys them as soon as it enrols, so a code with Log Collection ticked starts collecting logs immediately, with no further configuration.
Codes are single use: one code enrols one appliance, and codes do not expire: a code stays valid until it is used or deleted. If a code has already been used, generate a new one. After you generate a code, a "Waiting for an appliance to enrol" banner appears, polls live, and updates the moment the appliance comes online.
3. Create the VM
Size the VM for the capabilities you plan to run. The platform enforces these requirements, so an under-sized VM is rejected when you enable capabilities (section 7).
Minimum, always required
8 GB
4
50 GB
Base workload (always counted)
2 GB
2
16 GB
Network Detection (NDR)
+3 GB
+2
+16 GB
Log Collection
+1 GB
+0
+6 GB
Archiving
+1 GB
+0
+8 GB
Vulnerability Scanning
+8 GB
+4
+60 GB
Worked examples:
Log Collection only, or NDR + Log Collection (+ Archiving): the minimum covers it. Give the VM 4 vCPU, 8 GB RAM, 60 GB disk.
NDR + Log Collection + Vulnerability Scanning: give the VM 8 vCPU, 16 GB RAM, 100 GB disk (110 GB if you also enable Archiving).
Give the VM:
One NIC for management. It needs to be routable, with outbound access to the destinations in the network requirements table above.
One or more NICs for monitoring if you plan to run NDR. Connect these to a SPAN/mirror port (a switch port that receives a copy of other ports' traffic) or, on a virtual switch, to a port group in promiscuous mode (a setting that lets the NIC see all traffic on the port group).
For VMware, deploy the OVA and add a second NIC on the mirrored port group. For Hyper-V, create a Generation 1 VM with the VHD and enable port mirroring on the monitoring vNIC. For KVM or Proxmox, import the QCOW2 as the VM's disk (virtio recommended) and attach a second NIC to the mirrored bridge.
4. First configuration
There are two equivalent ways to do first-time setup. Pick one:
Option A, console wizard (section 4a): on the VM console or physical screen. This is the only option when the appliance didn't get a DHCP address you can browse to.
Option B, web UI first-run setup (section 4b): if the appliance got a DHCP address (shown on the console banner), you can skip the console entirely and do everything from the browser.
The appliance web UI uses a self-signed certificate, so your browser will warn when you connect. Accept the warning to proceed.
4a. Option A: console wizard
Open the VM console. The banner shows the appliance version, its DHCP address and the web UI URL. Log in with secops / secops (first boot only; the wizard makes you change the password).
The network configuration wizard starts automatically after login. Press Enter to begin.
Step 1: management interface. Pick the NIC that carries management traffic (the web UI and the appliance's outbound connection). Monitoring NICs are not configured here; you set those up later in the NDR section.
The wizard then offers to bond multiple interfaces (combine them into one logical interface for redundancy). Answer n unless you know you need it.
Step 2: hostname. This becomes the appliance's name in the portal fleet.
Step 3: timezone. Used for log timestamps and scan schedules, for example Australia/Sydney. Press Enter to keep UTC.
Step 4: proxy and OS mirror. If your site routes outbound traffic through an HTTP proxy, answer y and enter it. The appliance sends both management and data traffic through the proxy. The OS package mirror only needs changing on isolated sites with an internal mirror.
Step 5: IP address. Choose DHCP or static. Static asks for the IP in CIDR form (10.1.20.50/24), the gateway, and space-separated DNS servers. The wizard applies the settings and validates connectivity in place; the appliance does not restart at this step. If validation fails, the wizard rolls back to the previous network configuration so the appliance stays reachable, and you can run it again from the console menu.
The static branch, filled in and validated:
Step 6: management password. Sets the password for secops, used for both console and web UI logins from now on.
Done. The appliance now reboots once to finish applying everything; this is the only restart in the wizard. The banner then shows your hostname, and the default-password warning is gone:
4b. Option B: web UI first-run setup (no console needed)
If the appliance came up on DHCP, browse straight to https://<appliance-ip>:8952. The address is on the console banner, or you can find it on your DHCP server. Accept the certificate warning and sign in with the factory default secops / secops. A First-run setup wizard opens. It covers the same settings as the console wizard, in a different order with the password first, plus an optional activation step at the end:
1. Secure access. Replaces the factory password. This is required before anything else:
2. Hostname. The name the appliance reports under in the portal:
3. Time zone. A searchable dropdown, pre-filled from your browser:
4. Network. DHCP (shows the current lease) or static with IP, netmask, gateway and DNS. Note the warning: saving a static address changes the appliance IP and reboots it, so reconnect at the new address to continue:
5. Outbound proxy (optional) and 6. OS package mirror (optional). Same meaning as in the console wizard:
7. Activate (optional). Paste the activation code now, or leave it blank and activate later from the dashboard (section 5). Finish & reboot applies everything. Enrolment runs after the reboot, once the network is up:
If you activated here, skip section 5. After the reboot the appliance enrols itself and appears in the portal fleet.
5. Activate the appliance (web UI)
Browse to https://<appliance-ip>:8952 and sign in as secops with your new password.
The Overview page shows a three-step setup checklist. Paste the activation code from section 2 and click Activate.
Enrolment usually completes within a minute; allow up to five. The page updates to Enrolled, with the appliance ID, tenant and connection status:
If enrolment hasn't completed after five minutes, or activation shows an error: Run connectivity check. It tests every dependency from the network requirements table and names anything that is blocked. Run it before contacting support. If the activation code was already used, generate a new one in the portal.
Back in the portal, the Deploy and Codes banner changes to enrolled and the appliance appears in the fleet.
6. The appliance in the portal
Fleet Overview is the main page for daily monitoring: status tiles, a needs-attention list, and version and capability summaries across every appliance in the selected scope.
What the statuses mean:
online: the appliance has checked in within the last 30 minutes. Appliances check in about once a minute.
offline: no check-in for more than 30 minutes. Verify the VM is running and has network, then use the appliance web UI's connectivity check.
Needs attention also flags online appliances whose log collection has degraded: sources that are down, or silent (configured but no longer receiving events).
A Queued chip next to a version means an update has been requested and will install at the next check-in.
When a newer appliance version is available, an Update button appears next to the appliance, and Update tenant / Update MSP update every appliance in that scope at once. Updates install at the next check-in; monitoring and collection keep running while the update installs, though the appliance web UI may briefly show its "starting" page.
Click a fleet row to open the appliance. The Overview tab holds the location and description, the activation code it enrolled with, and lifecycle actions (rotate code, replace, decommission; see section 12).
7. Enable capabilities
Open the Capabilities tab and tick what this appliance should run. Changes land on the appliance at its next check-in, within about a minute, with no reboot:
Network Detection (NDR) analyses mirrored network traffic for threats
Log Collection receives syslog from your devices and forwards it to the platform
Archiving ships collected logs to your own S3 or SMB storage; pair it with a destination on the Archive tab (section 11)
Vulnerability Scanning runs network vulnerability scans from the appliance
The platform enforces the resource requirements from the table in section 3. If the VM is too small for the combination you tick, the change is rejected and the message tells you the exact shortfall:
To resize, shut the appliance down from the web UI (System & Updates → Shut down), increase the VM's RAM or vCPU in your hypervisor, power it back on, and tick the capabilities again.
The first deployment pulls container images, so allow 5 to 15 minutes depending on your bandwidth. Progress is visible in the appliance web UI (Pending → Running) and on the Fleet capability summary.
8. Add syslog sources
Open the Log Sources tab and click Add source. Pick the device type from the searchable catalog, which covers 50+ vendors:
Port rules:
11514 to 12514 are dedicated ports: no source IP needed, one device (or farm) per port. Prefer these.
514 (plain) and 6514 (TLS) are shared ports. Each source on a shared port must declare its source IPs, so the appliance can match incoming events to the right device. Enter a single IP or a CIDR block; separate multiple entries with commas. IP ranges (for example 10.0.0.1-10.0.0.50) are not supported.
Each source chooses TCP or UDP in the source form. TLS syslog is always TCP, on the shared TLS port 6514.
Tick TLS to receive syslog over TLS. The appliance presents its own certificate, so configure the sending device to trust it or to skip verification.
Some device types prompt for extra settings, for example a TIMEZONE for devices that stamp local time without an offset. On multi-tenant appliances, each source can be assigned to a specific tenant, so one appliance can collect for several of your tenants. Contact support if you'd like multi-tenant collection enabled.
The health indicator on each source row tracks what is actually arriving, not just whether the listener is up. A new source shows ready and changes to receiving once events arrive. A source that was receiving but has had no events for 15 minutes or more shows no recent data, which usually means the device stopped sending: check the device first. down means the listener itself is unhealthy.
Point your device at <appliance-ip>:<port> and watch the source's health indicator. If the device is sending but the source stays ready, open the appliance web UI, go to Log Collection and use Sample incoming syslog to see what's arriving on the wire and whether it matches a configured source.
8a. Webhook (HTTPS) sources
Cloud services that can't send syslog can push events over HTTPS instead. Webhook device types in the catalog create a source on the appliance's HTTPS ingest endpoint rather than on a syslog port. Enable the endpoint first in Webhook Ingest Settings, below the sources list:
Mode.
Off: no listener runs and nothing is exposed to the network.
Self-signed: HTTPS with the appliance's own certificate; no public DNS is published.
Public: the appliance gets a published hostname. Support provisions the DNS record and certificate and confirms the setup with you, so raise the request ahead of your change window.
HTTPS ingest port. The default is 8443. Use 443, 8443, or a port in the 11514 to 12514 range, and forward the port to the appliance if senders are outside your network.
Send-to address. Shown per source as
https://<address>:<port>/ingest/<source-id>/. Until a public hostname is published, the panel lists the appliance's LAN IP for senders on the same network and its public IP for port-forwarded senders. Once a hostname is published, the panel shows that instead.
Each webhook source row carries its credentials, either a password or a token in the URL, masked by default with a Show/Hide control. A Test reachability button probes that source's ingest endpoint end to end to confirm it's reachable.
9. Vulnerability scanning
Open the Vuln Scans tab and click New scan. Give it a label (lowercase letters, numbers and dashes), the targets (one CIDR or IP per line), and a daily or weekly schedule. The appliance and its own networks are always excluded automatically. Two dropdowns tune each scan:
Scan depth.
Standard: scans the roughly 6,000 registered TCP ports with the full vulnerability check set. Right for most environments.
Deep: scans every TCP port plus the most common UDP ports. Finds services hiding on unusual ports but takes several times longer.
Host discovery.
Standard: finds hosts by ICMP, TCP and ARP. Recommended.
ICMP ping only: fastest, but skips hosts that block ping.
TCP service ping: suits networks where ping is blocked but services listen.
Scan all addresses: skips nothing, alive or not. Much slower; best kept for small ranges.
On multi-tenant appliances a scan can also attribute its results to a specific tenant.
Results are sent to the platform as findings once each scheduled run completes. The first run cannot start until the vulnerability feed sync finishes; the sync is a large download on first deploy and can take an hour or more, so allow for that before expecting results. Unticking Enabled pauses the schedule without deleting the definition.
10. Set the NDR monitoring interface (appliance web UI)
NDR inspects whatever the monitoring NICs see, so after enabling the NDR capability, tell the appliance which interfaces those are. In the appliance web UI, open Network Detection:
Click Load available interfaces. It lists every NIC except management.
Click Check traffic to sample about 10 seconds of packets on one NIC, or Check all & recommend to check them all and pre-tick the busy ones. Use it when you're not sure which vNIC is the mirror.
Tick the interfaces cabled to the SPAN/mirror and click Set interfaces.
If you select two or more interfaces they are bonded automatically. The "Recent traffic" sample on the same page is the quickest way to confirm the mirror is delivering packets. NDR health takes a minute or two to become accurate after the feature starts, so wait before deciding something is wrong.
If Check traffic shows no packets on the interface you expected: verify the mirror/SPAN session is configured on the switch, that the port group has promiscuous mode enabled (VMware) or the port mirroring destination is set (Hyper-V), and that the vNIC you ticked is the one connected to the mirror.
11. Archiving
Open the Archive tab. Choose S3 / S3-compatible or SMB / CIFS, fill in the destination and click Save, then enable the Archiving capability (section 7) if it isn't already on.
Collected logs are archived hourly.
12. Ongoing operation
Appliance web UI
Network: management interface state, link details, proxy settings (with a no-proxy list), and re-running network configuration:
System & Updates: appliance version, OS patch state, the update trigger, and reboot / shut down controls:
Management password: change the
secopspassword after setup (the current password is required). The console menu has the same option.
Logs: a live appliance log viewer, filterable by Applications, Web access or System. This is the first stop when a source stays
readyor a capability sits in Pending:
Support → Remote engineer access: lets a support engineer connect over a built-in encrypted channel (endpoint
tps.deploydefend.io:443). It is off by default, fully under your control with explicit Turn on / Turn off buttons, and only available once the appliance is enrolled:
Support → Diagnostics: Download support bundle generates and downloads an encrypted bundle containing logs, redacted configuration, container states and connectivity results. Attach it to a support request. Only support can decrypt it, and it works even on an unenrolled appliance, which makes it useful for onboarding issues:
In the portal
Ongoing actions live on the appliance's Overview tab: Update appears when a newer version is available, Rotate code invalidates the activation code so it cannot be reused, Replace lets a rebuilt appliance take over this identity, and Decommission is the retirement path.
The Telemetry tab shows live CPU, RAM and disk trends, host resource gauges, the NDR traffic mix with health, and per-source event rates:
If something goes wrong
Lost the
secopspassword: contact support with the appliance ID. Every enrolled appliance has a recovery mechanism that support can use.Appliance unreachable after a network change: log in on the VM console and re-run Configure network from the console menu.
Appliance hardware failed or was rebuilt: deploy a fresh VM, run first-run setup, then use Replace on the old appliance's Overview tab so the new VM takes over its identity and configuration.
Quick reference
First-boot console login
secops / secops
Console/web login
secops (password set during first-run setup)
Appliance web UI
https://<appliance-ip>:8952
Portal location
Deployment → Appliances → Deploy and Codes
Dedicated syslog ports
11514 to 12514, TCP or UDP per source (no source IP needed)
Shared syslog ports
514 (plain, TCP or UDP) / 6514 (TLS, TCP only), source IPs required per source
Webhook HTTPS ingest
port 8443 by default (443, 8443, or 11514 to 12514)
Outbound access
see the network requirements table at the top of this page
Remote support endpoint
tps.deploydefend.io:443 (optional, off by default)
Minimum spec
4 vCPU / 8 GB / 50 GB; 8 vCPU / 16 GB / 100 GB with NDR, logs and scanning
Check-in interval
about once a minute; offline after 30 minutes of silence
Enrolment time
usually under 1 minute, allow up to 5
First capability deploy
5 to 15 minutes for image pulls; the first vulnerability feed sync can take an hour or more
Last updated