Firebreak Now available
Host-based segmentation for Linux and Windows servers
Stop lateral movement at the host.
See every connection between your servers. Allow only what runs your applications. Then confirm that each host actually enforces it. No network redesign, no inline appliance, and no application traffic through a controller.
Every server starts here. Firebreak reports what connects to what, and changes nothing.
Why segment servers
One compromised server shouldn’t mean many.
Inside a data center or a VPC, most servers can reach most other servers over RDP, SMB, SSH, WinRM and database ports, whether or not any application needs it. Perimeter firewalls rarely see that traffic. Attackers rely on it.
Firebreak puts the decision on every server. Segmentation doesn’t make a breach impossible. It shrinks what one compromised host can reach down to what its application actually needs.
Illustrative environment
How it works
Observe. Preview. Verify.
Segmentation projects stall when nobody is sure what will break. Firebreak keeps three things separate at every step: what was observed, what you intend, and what each host actually enforces.
Observation mode: nothing on these hosts is being blocked.
Policy model
Policy you can read, and predict.
Rules are written between tags, not IP addresses, so they survive re-IPs and new servers. They’re evaluated in one fixed order, so you can always tell which rule decides a connection, and why.
Evaluation order
Always allowed
Essentials no policy can cut off
Block rules
A block beats any allow
Allow rules
What your applications need
Temporary access
Approved, time-boxed, expires on the host
Everything else
Dropped. Default deny.
Enforcement modes
Start narrow. Go all the way when you’re ready.
Enforce only the ports you lock, for example RDP, SMB and WinRM across the whole fleet. Everything else stays observed.
22
SSH
observed
80
HTTP
observed
443
HTTPS
observed
445
SMB
locked
3389
RDP
locked
5432
Postgres
observed
5985
WinRM
locked
5986
WinRM/S
locked
9100
Metrics
observed
Tags, not IPs
Start with application, role, environment and location, then add your own. Tag rules fill in from hostname, IP or OS, and CSV import handles the rest.
A shared library
Services, nested service groups, IP lists and port ranges are defined once and reused across every rule.
Baselines
Shared rule sets for Linux essentials, Windows domain members, monitoring, jump-host management and blocking risky legacy protocols, with expiring exceptions and optional second-admin approval.
Scoped to a program
Narrow a rule to one program: a Windows executable or a Linux systemd service. Other software on the same port doesn't inherit the access.
Verified enforcement
“Requested” is not “enforced.”
It’s easy to call a server protected the moment a policy is sent. Firebreak doesn’t. Every host proves what its kernel is actually enforcing before the console says so, and backs out on its own if the confirmation never comes.
01
Signed
Policy is signed for one specific host, with a sequence number against replay and an expiry.
02
Trial
The host applies it on a trial basis, in its own firewall.
03
Read back
The host reads the kernel's actual rule state back and reports it.
04
Confirmed
The controller checks the report and sends a second signed confirmation.
05
Committed
Only now is the host shown as enforcing, in the console and the audit log.
Enforcement where the server runs
The firewall already on every server, finally managed as one.
Firebreak doesn’t put an appliance in the path or route traffic through a controller. It programs the host firewall each operating system already has, in a space of its own, and leaves the rest of the host alone.
nftables
Linux
- Firebreak's own nftables table. Your other host rules stay untouched.
- Runs alongside firewalld and SELinux in enforcing mode
- Rules can be scoped to a systemd service
table inet segmentation {
chain input {
type filter hook input priority 0;
# managed by Firebreak · signed policy
ip saddr @role_app tcp dport 5432 accept
ct state established,related accept
counter drop
}
}Windows Filtering Platform
Windows Server
- Firebreak's own WFP provider and sublayer
- Microsoft Defender stays on and in charge of its job
- Rules can be scoped to an executable path
WFP provider Firebreak
sublayer segmentation
filter permit tcp/443 from role:web
filter permit tcp/5432 from role:app
filter block * (default)
boot-time guards enabled
Microsoft Defender activeUnprivileged agent
The reporting agent runs without admin rights and buffers telemetry locally.
A constrained helper
Only a separate local helper may change the firewall, and only through signed, narrowly defined operations. It has no shell.
Out of the data path
Application traffic flows exactly as before. The controller never sees your packets.
Built for change control
Safe to run in production. Easy to run on a Tuesday.
Segmentation fails when it becomes the team that breaks things. Firebreak builds change management into the product, so you don’t have to bolt it on.
Canary rollouts
One host first, explicit approval to continue, pause at any point, and restore the previous policy in one step.
Guardrails that back out
Canary watch, new blocked traffic, and TCP/HTTP health checks can restore a rollout automatically.
Change windows & freezes
Rollouts respect maintenance windows, and freezes stop them outright.
Ticket checks
Require a valid ServiceNow or Jira ticket before a change goes out.
Temporary access
Request, approve (never your own), and let it expire. Expiry is enforced on the host, even if the controller is unreachable.
Break-glass
One local command returns a host to observation mode and writes an audit record on the host itself.
Notifications
Send rollout and change events to Slack, Microsoft Teams or any webhook.
Two-person control
Engineers propose and administrators publish. Baseline changes can require a second administrator.
Fits your stack
Enterprise plumbing, included.
Identity
- OIDC and SAML 2.0 single sign-on
- SCIM 2.0 provisioning
- Works with Okta and Microsoft Entra ID
- Argon2id local passwords as a fallback
Access control
- Viewer, Engineer and Administrator roles
- Service accounts with scoped keys
- Scopes such as policy.write and policy.deploy
Audit
- Every change in the activity log
- 400-day audit retention
- Signed daily archives
- Audit API for your own tooling
SIEM export
- Syslog over TLS, TCP or UDP
- Splunk HTTP Event Collector
- HTTPS JSON to any collector
API
- OpenAPI contract
- Idempotency keys and rate limits
- Signed webhooks
- Python client
Supported platforms
Linux and Windows servers, side by side.
One policy and one console for both. Agents are qualified release by release on specific operating-system builds. We confirm your exact builds and network setup when we scope an installation.
Linux
Ubuntu
Linux
Amazon Linux
Linux
Rocky Linux
Windows
Windows Server
x86-64 servers.
Deployment
Self-hosted, for one organization.
A Linux controller in your environment with its own certificate authority, database and signing keys.
- No internet requiredThe controller runs without internet access. An offline bundle carries everything it needs.
- Simple to operateInstall from the offline bundle or from .deb/.rpm packages, and manage it with one CLI.
- RecoverableNightly encrypted, signed backups, upgrade with rollback, and an optional warm standby.
- Keys held tightController keys are sealed with systemd credentials, bound to the TPM when one is present.
Do I need FireWeave to use Firebreak?+
No. Firebreak is an independent product with its own console, controller, agents and releases. Adopt either product on its own.
Does my traffic pass through Firebreak?+
No. Enforcement happens in each server's own firewall, nftables on Linux and the Windows Filtering Platform on Windows. Application traffic keeps its existing path and never touches the controller.
Can I watch before I block anything?+
Yes. Every server enrolls in observation mode. You can review its connections, draft rules and preview their impact against real traffic before an administrator turns on enforcement.
What if the controller is unreachable?+
Policy lives in each host's own firewall, so the host keeps enforcing what it last committed. Temporary access grants still expire on schedule, because expiry is enforced on the host.
How do we get out of enforcement in an emergency?+
Use break-glass. One local command returns the host to observation mode and writes an audit record on the host itself.
Is a policy request the same as protection?+
No, and the console never pretends otherwise. Each host trials the policy, reads its kernel state back, and commits only after a second signed confirmation. The console reports that committed state per host.
Does Firebreak use AI to make decisions?+
No. Enforcement runs on signed, deterministic policy that you wrote and previewed.
Is Firebreak offered as SaaS?+
No. Firebreak is self-hosted for a single organization, and its controller doesn't need internet access.
How is it priced?+
Pricing depends on your environment. Book a walkthrough and we'll scope the installation and commercial terms with you.
Start with one application.
We’ll walk through its real communication, the access policy it needs, and enforcement on its hosts, in your environment, with the engineers who build Firebreak.