← All guides

Lock machines down

GeoIP Access

Restrict which countries can reach your internet-facing machines — allow-only (e.g. USA) or block specific countries — per machine, per group or globally. SentinelOps has it because a huge share of attack traffic comes from regions a given client never does business with, and dropping it at the host removes that noise and attack surface outright. For the tenant it is a country-level firewall applied as nftables on internet-facing Linux hosts, with hard safety rails: your LAN, the SentinelOps server, established sessions and your allowlisted admin IPs are always allowed, and a failed country-data download aborts rather than loading a partial list — so a policy cannot lock you out.

Read before enabling

The amber banner at the top is the safety brief: allow-only mode drops every country except those you list; before enabling, make sure your own admin IP is on the Blocked-IPs never-block allowlist, and start with the “SSH/RDP/WinRM” port scope (not “all”) on any server that also serves public web or mail.

Create a policy — field by field

Name it. Mode: “Allow only these countries” or “Block these countries”. Countries: ISO codes, comma-separated (e.g. US, CA). Applies to: All external machines (global), A group, or A single machine (the machine dropdown lists Linux hosts only). Enforce on: SSH/RDP/WinRM (admin — the safe default), + web (80/443), or All inbound ports. “Enforce now on save” applies it immediately (you are asked to confirm). Create policy saves it.

Policies table

Each row shows the policy name with its mode and country list, its scope, the enforced ports, state (enforced / off), and the last-apply status (a red detail line surfaces the machine’s own error). Apply now re-applies to its machines on demand, Edit changes mode / countries / ports / enforced, and ✕ deletes the policy and removes its firewall rules from the hosts.

How “applied” is counted

“applied to N host(s)” means the firewall is live on N machines. “0 host(s)” with no error means nothing in scope qualified — offline, internal-only, not Linux, or a hypervisor host (which is never firewalled). A red GEO_ERROR shows the machine’s own error, and a failed refresh never removes rules already in force.

Apply cadence and Windows

Policies re-apply every 12 hours to pick up fresh country ranges and survive reboots; Apply now forces it. GeoIP is NOT enforced on Windows yet — it uses the Linux firewall — so protect Windows hosts with the per-IP auto-block (Blocked IPs) and your edge firewall.

Blocked IPs / SSH

Brute-force and SSH attack sources dropped at the attacked host’s own firewall, the controls that govern that blocking, and the agent-port firewall allowlist. SentinelOps has it because internet-facing machines are hammered constantly, and the fastest place to stop an attacker is on the endpoint being attacked. For the tenant it means brute-force sources are shed automatically — while your LAN, neighbours, discovered and trusted IPs and the SentinelOps server are always spared — with a console allowlist that can never lock you out. Changing policy needs tenant.manage; blocking/allowing needs command.execute.

Console allowlist — auto-follow a DNS / DDNS name

The console (ports 443/8480) is firewalled to an allowlist. Add a dynamic-DNS name (e.g. your home/office home.example.com) and SentinelOps re-resolves it every 60 seconds and keeps its live IP allowed, so an ISP IP rotation never locks you out. Connecting over the WireGuard VPN bypasses this entirely. Only a global operator can manage this list.

Automatic brute-force blocking

Toggle “Auto-block brute-force sources (incl. SSH)” to enable enforcement. “Monitor only (report, don’t block)” records what WOULD be blocked without pushing any firewall rule — use it to validate before enforcing. Threshold (failed logons) is the trip point, default 10. When a public IP passes it, the attacked machine’s firewall drops it; a private / same-subnet / ARP-neighbour / discovered / trusted IP or the SentinelOps server is never blocked. Save applies the settings live.

Expiry fields

Auto-block expiry (days, 0 = never) lifts an AUTOMATIC block after that many days and removes the host firewall rule too. Candidate expiry (days) drops monitor-only “would block” records after that many days (blank/0 = default 30). Manual blocks never expire.

Allowlist and disabled networks

The never-block allowlist (one IP or CIDR per line) is always spared — put your trusted/admin networks here. “Networks where auto-block is disabled” is only for sparing a specific PUBLIC subnet; internal/private LANs are already exempt automatically because only internet-facing machines are ever auto-blocked.

Manually block / unblock

With command.execute, “Manually block an IP on a device” takes an IP plus a target machine (online, non-mobile) and blocks it on the spot. Every active block in the table has an Unblock button. In monitor-only mode a “would block” candidate also offers “Block now” to promote it to a real block.

Would block / Active blocks tables

The Would-block (monitor-only) table lists candidates that crossed the threshold but had no rule pushed. The Active blocks table lists each enforced block with its source (auto vs manual), the device enforcing it, the reason, the attacker’s origin (flag + city, geolocated in the background), and when it was blocked. Click any IP to trace it — ownership (RDAP), origin, the full cross-fleet attack trail, and to report it to its abuse desk.

Allowed through the agent firewall

The agent port (8480) is locked to an allowlist; this panel lists the IPs SentinelOps let through — a new machine that port-knocked with a valid deployment token, or a cloud VM we provisioned. A “seed” grant is a hand-configured IP and is never auto-pruned; other grants are reaped when their device is decommissioned or the cloud IP is abandoned. With command.execute you can manually Allow an IP (IPv4 or IPv6), Revoke a grant, or tick “never” to pin an IP open permanently (no reaper, device-removal or auto-block ever strips a pinned IP).

Security Dashboard

One rollup of everything SentinelOps blocks, monitors and reports across every machine — endpoints and hypervisors alike. SentinelOps has it so an operator opens a single screen and immediately knows where a tenant stands on each security area and where to go next. For the tenant it is the security home page: six live cards that link straight into the detail view that owns each area, plus quick jumps to configure the rules behind them. Scoped to the tenant selected in the top bar, or the whole fleet when none is selected.

The six cards

Blocked IPs (SSH & brute-force) — active blocks, how many would-block candidates, and whether blocking is enforcing or monitor-only. Open vulnerabilities — total CVEs with critical / high / exploited detail. Security posture — the count of attention items. Endpoint security — endpoints at risk on encryption / firewall / AV. Identity security — risky accounts. Hypervisor security — hosts passing of those scanned. A card turns red when its area is non-zero, and clicking any card opens its full view.

Honest when a source is down

Each card is loaded independently; if one source fails it degrades gracefully (shows “—” / “not run”) while the rest still render — the dashboard never blanks because one area is unavailable.

Define what’s monitored & blocked

A row of buttons jumps you to the screens that configure each area: IP blocking & SSH, Hypervisor security, Vulnerability management, Config baselines, File integrity, TLS scanner, DNS monitoring, and Monitor rules & alerts. Use it as the launcher for setting the rules behind the cards.

Vulnerabilities

Fleet CVE exposure from TWO sources: CVEs the OS updater attaches to patches you have not applied, and an offline scan that matches each machine’s installed packages against a locally-synced OSV + CISA-KEV database (so it finds CVEs even when no patch is on offer). SentinelOps has it because knowing you are behind on patches is not the same as knowing which of those gaps attackers are actually exploiting. For the tenant it is a prioritised remediation queue — exploited-in-the-wild issues first — with a one-click fix on each finding. Works across the fleet, or scoped to the selected tenant.

The exposure KPIs — click to drill in

Four tiles: Unique CVEs, Exploited in wild (CISA Known Exploited), Critical, and Affected devices; the exploited and critical tiles warn when non-zero. Clicking a tile filters a highlighted panel to the matching findings from the offline scanner (exploited / critical / high / all), or, for Affected devices, the endpoints with findings — each row opens the device. A “clear ✕” link removes the filter.

From missing patches

The first table is CVEs the OS updater ties to updates you have not applied, with severity, an “exploited” pill, the affected-device count (the blast radius) and the products affected. Each CVE links to its NVD detail page. Empty here means no CVE-tagged missing patches — run a patch scan to refresh.

Offline CVE-database scan

The second panel matches installed packages against the synced OSV + CISA-KEV database and rolls findings up by CVE across machines (exploited and highest-severity first). Linux distro packages are matched today; Windows third-party apps need the NVD/CPE follow-up. The panel header shows the database size, how many are known-exploited, and when it was last synced.

Scan now / Sync CVE database

Header and panel buttons: “Scan now” (needs device.read) re-scans installed packages against the database and reloads the view; “Sync CVE database” (needs operator.manage) re-downloads the offline OSV + KEV database (a few minutes) — run Scan after it finishes. If the panel says the database is not synced yet, Sync first, then Scan.

Fix a finding

Every finding has a “Fix ▸” button that opens remediation: the severity, package → fixed version, a summary, step-by-step “How to fix”, reference links, and where available a generated fix script you can Copy. With command.execute you can “Run fix on <device>” (it then nudges a fresh inventory and auto re-scans so the finding clears on its own), “Repair install (clean reinstall)” when a broken updater can’t advance the app, and on Windows “View install log” to read the endpoint’s SentinelOps install/update log without visiting the machine.

Next: Enroll Korthveil firewalls →