Network containment is one of the most useful response controls in CrowdStrike Falcon. When a host may be compromised, containment quickly isolates it from the rest of the network while preserving the Falcon sensor’s connection to the CrowdStrike cloud.
That isolation also creates an operational problem: it can sever the endpoint’s connection to NinjaOne. The device then appears offline in the NinjaOne console, and responders lose a second management channel that could otherwise help with triage, evidence collection, scripting, or recovery.
This post documents the containment-policy exceptions I have used to keep the NinjaOne agent communicating from CrowdStrike-contained Windows hosts in NinjaOne’s NA region, which NinjaOne identifies as its US East and US West 2 region.
Important distinction: The goal is to keep the NinjaOne agent connected so the endpoint remains visible and manageable from the NinjaOne console. This is not a recommendation to browse to the NinjaOne web console from the contained endpoint.
How CrowdStrike network containment behaves
When Falcon receives a network-containment request, the sensor blocks existing and new inbound and outbound connections except for its own CrowdStrike cloud communication and any traffic explicitly permitted by the containment policy. Containment remains active across reboots and even if the sensor temporarily loses its cloud connection.
Falcon containment policies can permit:
- IP ranges
- DNS servers
- Fully qualified domain names (FQDNs)
There are important sensor-version and platform limitations:
- DNS containment rules require Falcon sensor for Windows 7.33 or later.
- FQDN containment rules require Falcon sensor for Windows 7.33 or later or Falcon sensor for macOS 7.39 or later.
- Falcon’s supplied documentation does not list FQDN containment support for Linux. An IP-only design is harder to maintain because NinjaOne recommends URL-based allowlisting for dynamically assigned services.
- Network containment is not supported when a Linux Falcon sensor is in Reduced Functionality Mode.
For those reasons, the approach below is primarily aimed at current Windows sensors.
Confirm the NinjaOne region first
NinjaOne’s region names are easy to misread. In its documentation, NA and US2 are separate regions:
- NA / US West 2: the standard tenant URL contains
app.ninjarmm.com. - US2 / US East 2: the standard tenant URL contains
us2.ninjarmm.com.
The companion workbook contains entries I have used across both NA and US2 environments, along with conditional SASE and feature-specific exceptions. For an NA-only deployment, do not blindly copy the US2 rows. Start with the NA requirements and add only what your enabled NinjaOne features actually use.
Companion file: NinjaOne RMM CrowdStrike Allowlist.xlsx
Build the CrowdStrike containment allowlist
In the Falcon console, navigate to:
Host setup and management > Response and containment > Containment policy, then select Create allowlist.
I recommend building and testing this as a dedicated NinjaOne containment policy rather than mixing the rules into an unrelated exception set. Give every entry a descriptive name that identifies the service, region, and reason for the exception.
1. Allow a trusted DNS resolver
FQDN rules depend on DNS resolution that the Falcon sensor can observe. Add the DNS server or servers the endpoint will actually use while contained.
My testing workbook includes several public resolvers because it was used with endpoints on different networks. That does not mean every resolver should be allowed in every production policy. Prefer organization-controlled DNS whenever possible, and permit only the resolver set required for the affected endpoints. Keep in mind that organization-controlled DNS sometimes means Active Directory DNS servers. During a network containment scenario, you may not want your endpoint communicating with ADDS DNS.
Security note: FQDN containment cannot function properly when DNS is hidden by encrypted DNS protocols such as DoH, DoT, DoQ, or DoH3. It also relies on the integrity of the DNS response. Test the endpoint’s real DNS behavior, not merely the address written in a policy document.
2. Add the NA regional IP gateways
As of August 11, 2026, NinjaOne’s NA regional documentation lists these IP gateways:
| Rule type | Suggested name | Rule |
|---|---|---|
| IP Range | NinjaOne NA Gateway 1 | 52.33.253.235/32 |
| IP Range | NinjaOne NA Gateway 2 | 34.212.188.161/32 |
| IP Range | NinjaOne NA Gateway 3 | 35.163.67.164/32 |
3. Add the core FQDN rules
The most compact policy uses NinjaOne’s parent domains with Falcon’s Allow subdomains option. CrowdStrike notes that this option permits only one level below the named domain. For example, allowing subdomains of ninjarmm.com permits app.ninjarmm.com, but not a hypothetical two-level name such as service.region.ninjarmm.com.
| FQDN | Allow subdomains? | Purpose or caution |
|---|---|---|
ninjarmm.com |
Yes | Core NinjaOne agent, patcher, WebSocket, rendezvous, and related NA services. |
ninjarmm.net |
Yes | NinjaOne Remote and related relay names. Add only if remote-response capability is required during containment. |
rmmservice.com |
Yes | NA branded NinjaOne URLs. Needed only when the tenant or agent uses this branded domain. |
ingest.sentry.io |
Yes | Listed by NinjaOne as a global requirement. This is a shared service domain; validate the need and risk with your security team. |
ninja-attachments.s3.us-west-2.amazonaws.com |
No | NA attachment storage. |
ninjauploads.s3.amazonaws.com |
No | Agent and patcher upload service. |
ninja-catalog-release.s3.us-east-1.amazonaws.com |
No | Agent patcher catalog. |
The ninjarmm.com parent rule covers the one-level hostnames NinjaOne currently lists for the NA agent and patcher, including:
app.ninjarmm.comrtc-us-west-1.ninjarmm.comrtc-us-west-2.ninjarmm.comconnect-us-west.ninjarmm.comconnect-us-west-s0.ninjarmm.comthroughconnect-us-west-s71.ninjarmm.comfts-prod-oregon-1.ninjarmm.comfts-prod-oregon-2.ninjarmm.comfts-prod-oregon.ninjarmm.comfts-prod-ohio.ninjarmm.comresources.ninjarmm.compatching.ninjarmm.comagent-app.ninjarmm.com
If your policy prohibits parent-domain exceptions, create exact FQDN entries instead. The tradeoff is obvious: the policy becomes narrower, but it also becomes much longer and more likely to break when NinjaOne changes its service inventory.
Once I added these items in my dev environment, I still had trouble connecting via remote CMD/shell and remote screen share. I opened a monitor session during network containment and noted that the following URL was acting as a call-home which was being blocked. Once added, I could establish remote CMD/shell and remote screen share during a containment scenario.
us-east-2.amazonaws.com
Conditional rules: add only what you use
The following categories appeared in my broader working list or in NinjaOne’s documentation, but they are not all required for basic NA agent check-in.
NinjaOne Remote
NinjaOne Remote primarily uses outbound TCP 443, with TCP 7075 as a fallback. Peer-to-peer performance may also use optional UDP ports. NinjaOne has moved Remote toward static routing and publishes region-specific relay names and IPs.
If remote control must work while a host is contained, test that feature separately. Basic agent check-in can succeed while interactive Remote, file transfer, or background tools still fail. The ninjarmm.net parent-domain rule may cover the published NA relay names, but organizations using IP-only controls should consult the current NA regional list before adding the Remote static IPs.
Cloud RDP, File Explorer, Backup, MDM, and NMS
These NinjaOne modules use additional endpoints. Do not add their rules merely because they exist in vendor documentation. Add them when the feature is licensed, enabled, and part of the incident-response plan:
- Cloud RDP uses
agent-tun-*andtun-*endpoints. - Device Backup uses region-specific Amazon S3 buckets.
- NA MDM uses
mdm-app.ninjarmm.comandscep-app.ninjarmm.com. - File Explorer uses the published
fts-*rendezvous endpoints.
SASE and SD-WAN anchor subnets
NinjaOne’s global documentation lists special “key subnet” values for certain SASE and SD-WAN vendors. My workbook includes the documented Zscaler, Todyl, and Netskope values because I was testing across varied environments. These are conditional integration anchors, not universal NinjaOne destinations.
Do not add all three. Add only the subnet associated with a service your organization actually uses and only after validating the behavior with the appropriate network team.
US2 entries
Rows containing names such as us2.ninjarmm.com, rmmservices.net, agent-us2.us2.ninjarmm.com, or nc-1.us2.ninjarmm.com belong to NinjaOne’s US2 / US East 2 environment. They are not required for an NA-only tenant unless your organization has a documented cross-region use case.
Test before an incident
CrowdStrike specifically recommends testing containment exceptions with the internal IT and networking teams before relying on them in production. That advice is not boilerplate. FQDN behavior, DNS visibility, proxies, SSL inspection, enabled NinjaOne modules, and sensor versions can all change the result.
- Use a non-production Windows endpoint with current CrowdStrike and NinjaOne agents. I tested mine on DEVHOST01V in my Hyper-V environment.
- Confirm the Falcon sensor version supports DNS and FQDN containment rules.
- Record the endpoint’s active DNS servers, proxy configuration, NinjaOne tenant URL, and enabled NinjaOne modules.
- Apply the candidate containment policy.
- Network contain the test endpoint.
- Verify that Falcon reports the host as contained, not merely Containment pending.
- Confirm the endpoint remains online in NinjaOne and continues checking in.
- Run a harmless script or command through NinjaOne to prove two-way management.
- Separately test any required Remote, file-transfer, background, backup, or MDM function.
- Reboot the endpoint while contained and repeat the tests.
- Review the policy and remove every exception that was not required.
Also test from the networks your responders will actually encounter. A laptop on the corporate LAN, a home network, a cellular hotspot, and a hotel network may use different DNS and proxy paths.
Security tradeoffs
Every containment exception weakens containment by design. The objective is not to make every NinjaOne feature function exactly as it does on an unrestricted endpoint. The objective is to preserve the smallest management path responders genuinely need. I intentionally did not allow NinjaOne backups to prevent an overwrite of a good, clean image with a compromised image.
- Prefer trusted internal DNS over a long list of public resolvers.
- Avoid broad multi-tenant domains unless testing proves they are necessary. For example, allowing subdomains of
cloudfront.netcan create a much larger exception than most organizations intend. - Do not add SASE anchor subnets for products you do not use.
- Do not mix NA and US2 rules without a documented requirement.
- Review the allowlist when NinjaOne announces networking changes and after major Falcon sensor upgrades.
- Maintain an emergency method to lift containment through Falcon if the secondary management path fails.
Final thoughts
Keeping NinjaOne available during CrowdStrike network containment can give responders a valuable second path to an isolated system. Done carefully, it improves operational resilience without materially undermining the purpose of containment.
The key is scope: confirm the NinjaOne region, allow trusted DNS, add the required NA gateways and service domains, test each needed capability, and remove anything that does not earn its place in the policy.
Planning is theory. Operations are reality. A spreadsheet is a good start, but the real proof is a contained endpoint that still checks in after a reboot.
References
- NinjaOne Global Allowlist Information
- NinjaOne Allowlist: NA Region
- NinjaOne Allowlist: US2 Region
- CrowdStrike: What is Endpoint Detection and Response?
This article reflects vendor documentation and lab/production testing available as of August 11, 2026. Cloud service endpoints and product behavior change. Validate all rules against current CrowdStrike and NinjaOne documentation before deploying them.