Skills and requirements
The console is point-and-click, but a sensor is a Linux machine on your network that you install, look after and troubleshoot. Whoever deploys sensors needs basic Linux administration skills. This page explains what that means and what the sensor host needs. Skills you need You should be comfortable doing all of the following without step-by-step help: Skill Why a sensor needs it Set up a Linux host or VM The sensor runs on a Linux machine you provide, usually a dedicated virtual machine. You install a supported distribution and give it a network address. Work as root The install command must run as root (it's piped into sudo sh). Install and run Docker The agent and its scanners run as Docker containers. The installer can install Docker from your distribution's packages, but you should be able to check it's running and start it if it isn't. Manage systemd services Docker runs as a systemd service. You should know systemctl status, systemctl start and systemctl enable. Read logs You'll use docker logs for the agent and journalctl for Docker itself when something goes wrong. Firewalls and outbound access The sensor needs outbound HTTPS to the console and to the container registry it pulls images from. You may need to allow that in your firewall or proxy, and allow the sensor's scans through any firewalls between it and its targets. Basic networking You need to know your IP ranges and CIDR notation (for example 10.0.0.0/24), how DNS resolves names on your network, and how VLANs and routing decide what the sensor can reach. A sensor only finds what it can reach. Time sync The sensor's clock must be within 15 minutes of the server's, or it's refused. Keep NTP time sync on. Keep the host patched Orbital updates the agent and scanners, but the operating system is yours to update, like any other server. [!TIP] If you're happy installing a Linux VM, running a few commands with sudo, and reading a log to work out why a service won't start, you have the skills you need. Who this isn't for Sensors aren't a good fit if nobody in your team can do the things above. In that case: Ask your IT provider or a Linux administrator to set up and look after the sensor for you. Once it's online, everything else happens in the console. Use Cloud scanners for your internet-facing systems (websites, VPN gateways, mail servers). There's nothing to install, though they depend on your plan and can only reach public addresses. Use Endpoint agents to see what's installed on your computers. They install with a Windows installer, a macOS package or one command. Host requirements Operating system The installer supports: Ubuntu 22.04 or 24.04 Debian 12 Red Hat Enterprise Linux, Rocky Linux or AlmaLinux 9 On other distributions the installer warns that the platform isn't supported and continues anyway. It can install Docker for you only on Ubuntu, Debian, RHEL, Rocky Linux and AlmaLinux; elsewhere, install Docker yourself first. Processor architecture Use x86_64 (amd64) for production sensors. arm64 is supported for testing only. Other architectures aren't supported. CPU, memory and disk When the agent starts, it checks the host and picks the highest capability the host qualifies for. The capability decides which scan types the sensor can run. Capability CPU Memory Free disk Scan types Lite 2 cores 2 GB 10 GB Discovery, Nuclei, WordPress, TLS Standard (recommended) 4 cores 8 GB 30 GB Lite, plus network vulnerability scanning (OpenVAS), Active Directory assessments and cloud posture assessments Performance 8 cores 16 GB 60 GB Same as Standard, scanning more hosts in parallel A host below the Lite level shows as Below minimum and can't scan. Hosts slightly under these sizes still qualify (a VM with "8 GB" of memory reports a little less after the kernel's share). [!NOTE] Active Directory assessments and cloud posture assessments also depend on your plan. See Subscription. Network Outbound HTTPS to the console address in the install command. The sensor doesn't need…
OrbitalCyber documentation