Posted in

Network Detection and Response

by andrewtravis0

In a past life as a member of a Blue Team providing defensive security, I loved tapping critical points of the network and mirroring that traffic to an IDS, then to our SIEM so that we could detect malicious and anomalous behavior on the network.  Naturally I had to play with a Network Detection and Response (NDR) solution to see what information it could provide.  NDR is meant to establish a baseline of “normal” and then alert to anomalies using machine learning.  It can also supplement a sandbox solution to detect malware and notify a firewall to block it (when using inline blocking).  In this blog post I wanted to outline the FortiNDR solution, how you can deploy it and what the interface looks like.

Deployment Scenarios

As I was deploying FortiNDR, I soon discovered that there are multiple deployment scenarios depending on the desired function. In the diagram below (taken from our FortiNDR Product Management team), FortiNDR is in the middle and can operate in any of the following modes (and any combination of them, it’s not one or the other):

  1. Sniffer Mode
  2. Integrated Mode
  3. ICAP Mode
  4. Other / API Mode

You can read more about the different operating modes on the Documents Library: https://docs2.fortinet.com/document/fortindr/7.1.0/administration-guide/188840/operating-mode-protocols-and-file-type-support. Depending on your goals, FortiNDR has two main use cases:

Malware Detection

  • Deploy FortiNDR as ICAP Server (ICAP Operating Mode), sources would intercept HTTP/S traffic and forward files to FortiNDR.
  • Deploy FortiNDR as a “FortiSandbox” Fabric Connector on FortiGate (Integrated Operating Mode), sources would intercept HTTP/S, SMTP, POP3, IMAP, FTP, CIFS traffic and forward files to FortiNDR.
  • Deploy FortiNDR with API integrated into a SOAR solution to upload files to it (API Operating Mode) and render a verdict.

Lateral Movement Detection / Anomalous Activity

  • Deploy FortiNDR and Mirror Traffic to It (Sniffer Operating Mode)
  • Deploy FortiNDR as NetFlow Collector (more on this below)

Methods to Send Traffic to FortiNDR

The following are methods to send traffic to FortiNDR.  The optimal solution is to Tap or SPAN all traffic to FortiNDR to detect Lateral Movement, but that often isn’t feasible.  And depending on placement of the sourced traffic, it could be encrypted and less valuable (but still valuable using JA3 hashes).  The following options are listed in (my opinion) in order of effectiveness as well as highest level of effort required:

1. Perform SSL Decryption on the FortiGate and then Mirror to FortiNDR:

2. Use a SPAN/RSPAN/ERSPAN to Mirror Traffic to FortiNDR:

3. Send NetFlow to FortiNDR (introduced in v7.2):

Sniffer Operating Mode Configuration

In my lab, I opted to SPAN traffic from many servers to my FortiNDR VM, just to get it up and running. Since I’m running FortiNDR VM and SPANning traffic to it, it was time to buy that extra NIC for my ESXi server to listen to the SPAN traffic…. I configured the Sniffer interface on FortiNDR VM on a Port-Group mapped to the SPAN port on the FortiSwitch:

Note that since the switch will mirror all VLANs, I needed to setup my Port Group to use VLAN 4095 — the equivalent of all VLANs in ESXi. I then configured the FortiSwitch to mirror traffic from the servers (port15 on the switch below) to the ESXi vSwitch with the Sniffer network (port16 on the switch below, connected to vmnic1 in ESXi):

FGT# config switch-controller managed-switch
FGT (managed-switch) # edit S124FPT1234567
FGT (S124FPT1234567) # config mirror
FGT (mirror) # edit “Sniffer”
FGT (FGT-Uplink) # set status active
FGT (FGT-Uplink) # set switching-packet enable
FGT (FGT-Uplink) # set dst “port16”
FGT (FGT-Uplink) # set src-ingress “port15”
FGT (FGT-Uplink) # set src-egress “port15”
FGT (FGT-Uplink) # next
FGT (mirror) # end

NetFlow Collector Configuration

I wanted to improve my visibility of devices outside my ESXi environment by sending NetFlow from my border FortiGate to FortiNDR; the first step is to enable NetFlow on FortiNDR so that it can verify the license (NetFlow requires an add-on license):

FortiNDR-VM# exec netflow on

netflow is on now

Now I’m ready to configured my FortiGate to send NetFlow to FortiNDR:

HomeLab-FortiGate-101F-A # config sys netflow

HomeLab-FortiGate-101F-A (netflow) # set collector-ip 192.168.5.130

HomeLab-FortiGate-101F-A (netflow) # set collector-port 2055

HomeLab-FortiGate-101F-A (netflow) # set source-ip 192.168.5.1

HomeLab-FortiGate-101F-A (netflow) # show
config system netflow
set collector-ip 192.168.5.130
set source-ip 192.168.5.1
end

HomeLab-FortiGate-101F-A (netflow) # end

HomeLab-FortiGate-101F-A # config system interface

HomeLab-FortiGate-101F-A (IoT) # edit “IoT”

HomeLab-FortiGate-101F-A (IoT) # set netflow-sampler both

HomeLab-FortiGate-101F-A (IoT) # next

Now if you check FortiNDR, you’ll see traffic in the NetFlow Dashboard:

FortiSandbox Integration

The FortiSandbox deployment with an integrated FortiNDR can increase detection coverage and overall throughput. Submitted files goes through the following logic:

1. FortiSandbox performs its pre-filtering and Static Scan analysis. If any known malware is found, the result is returned.

2. When FortiAI Entrust is enabled under FortiSandbox Scan Profile, FortiSandbox sends the files to FortiNDR via API for FortiNDR’s verdict of malware or absolute clean, and the result is returned. FortiNDR uses its patented malware detection engine to analyze the file using the following flow:

If a file is not absolute clean, then the next step is performed.

3. FortiSandbox performs its Dynamic Scan analysis to capture any IOC.

https://docs2.fortinet.com/document/fortindr/7.1.0/administration-guide/43951/fortisandbox-integration-fortisandbox-4-0-1-and-higher

The advantage to using FortiNDR in this scenario is that it can lighten the load on FortiSandbox’s Dynamic Scan by rendering a verdict beforehand.

You can see the flow in the diagram of my Home Lab above:

  1. Using an AV Security Profile on the FortiGate, the FortiGate sends the file to FortiSandbox for analysis. If the FortiGate is configured for inline blocking, it holds the file until it receives a verdict from FortiSandbox. Otherwise FortiGate delivers the file and performs the analysis out of band.
  2. FortiSandbox performs a Static Scan which is comprised of pre-filtering, full antivirus scan, cloud query and Static AI scan. It’s not as effective as a Dynamic Scan, but it’s much faster.
  3. FortiSandbox sends the file to FortiNDR, where FortiNDR uses its patented malware detection engine to analyze the file and identify features matching malware attributes.
  4. FortiNDR uses it’s Artificial Neural Network to determine if the file is malicious or not and renders a verdict to FortiSandbox
  5. If FortiNDR isn’t sure if the file is malicious or not, FortiSandbox will perform a Dynamic Scan where it runs the file in a sandbox and observes its behavior.
  6. Depending on the analysis of the file’s behavior, it will send a verdict back to FortiGate if it should block the file or not.
  7. In this last step, FortiGate will either block the file (if inline) or send notification via SOAR, log, etc. to the security team to investigate the endpoint that received the file.

Conclusion

This summarizes my post on feeding data into FortiNDR and integrating it with FortiGate and FortiSandbox. I’ll write a follow up post on how to utilize FortiNDR to detect malicious activity on your network. Thanks for reading!

Leave a Reply

Your email address will not be published. Required fields are marked *