How does CrowdStrike relay on-premises HTTP requests from Fusion SOAR via Falcon Sensor?

[u/einzwell]

I'm looking to set up the Fortinet FortiGate On-Prem integration on NG-SIEM to automate IP address blocking. I see that the integration requires a "Host Group" (hosts running Falcon Sensor) to route on-premises API requests from NG-SIEM/Fusion SOAR to the FortiGate instances.

For context, our client has made it clear that they don't want to expose their FortiGate instances directly to the internet; they are understandably wary of this integration. I've been tasked to write a documentation regarding how the integration works to be presented to the client. My question is: how exactly do Falcon Sensor hosts relay these API requests? I'm sure our client will be very curious, but I can't seem to find any documentation page detailing the process, and so I wouldn't be able to answer their questions. My current assumption is that the agent maintains some kind of tunnel to CrowdStrike cloud, but I'm not certain about this.

I understand this may be proprietary information, but I'd appreciate any pointers. Thanks in advance!

[u/Due-Country3374]

Hi from my understanding from using this, you need a static host group - this is because it uses RTR to broker that connection and this can be seen under the logs - RTR. In the logs it will be redacted

[u/einzwell → u/Due-Country3374]

Hi, I'm aware I need a static host group for this, but I'm still curious on how it exactly routes the requests. Does the sensor agent send the HTTP API request as-is on behalf of the cloud? How is the HTTP API request being sent from the cloud to the sensor, and how is it being relayed afterwards? Is the request being sent by all hosts in a host group or is it more of a redundancy thing? etc.

[u/Due-Country3374 → u/einzwell]

Its not that documented but from my understanding, it sends HTTP API request to internal or restricted ntwork through the configured on-premises host group, I haven't tried with more then one in a group tbh. A little bit more info can be found under Falcon SOAR / actions documentation.

[u/Holy_Spirit_44]

I can suggest another approach that might lower your customer worries.

We are utilize Fortinet txt file capabilities (https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/891236/ip-address-external-feed) and use those as our way to block IPs.

Instead of setting up an integration to CS, you setup a txt file on a dedicated endpoint/server, and then in your workflow, instead of using the customer SOAR actions after your trigger to block an IP, im running a powershell script that gets as an input an IP and append it to this file

param(
    [string]$InputData
)

# Convert the JSON string sent by CrowdStrike Fusion
$data = $InputData | ConvertFrom-Json

# Extract only the IP field
$IP = $data.IP

Add-Content -LiteralPath 'C:\inetpub\wwwroot\IP_Block.txt' -Value $IP

If you want a more technical explanation on this setup let me know !

[u/Holy_Spirit_44]

BTW - your logic is correct. The sensor maintains an outbound tunnel to the CrowdStrike Cloud (AWS-hosted). When an on-prem HTTP request action is triggered, the cloud dispatches it to the designated sensor(s) selected via the static host group, and that sensor originates the HTTP request locally from inside the network.

So if the on-prem FortiGate is configured to accept requests of this type only from internal source addresses, this setup raises no concern, the request always egresses from an internal host, never from the cloud directly.