| Solution |
About Isolation:
- ICMP is not blocked in isolation.
- TCP and UDP communication is blocked, ICMP is not blocked, ping would still work.
- By design - ICMP (aka ping) are allowed on an isolated unit, as such may assist IT in determining that the machine is on and physically connected to the network.
- The isolation is done by a 3rd party tool (it originally came as a feature request.
- SMB is also available for remote file access under isolated units- the main technical reason is related to false-positives and the automated incident response recipes, which want to encourage without the business disruption.
- On top of it the SMB access is useless in a completely covered endpoint environment, as the attacker can't send it out either way. The default SMB behavior upon isolation is configurable, and can be changed with a relevant Core configuration.
Testing Isolation.
If the connection is established it will keep alive, hence the test should ensure closing the socket first, namely end Remote Desktop session and disconnect is required.
Additional clarifications here about isolation.
- When a collector is isolated, currently alive and keep-alive connection is not.
- Blocked: Isolation blocks TCP and UDP communications, do not block ICMP, ping would still work.
- In isolation mode incoming RDP is not blocked and also ICMP this is by design.
- Isolation mode as well as any Communication Control denial that is performed by the FortiEDR Collector takes effect only on new network sessions.
- Connections that were established prior to device isolation would not reset upon device isolation.
- In addition, incoming RDP connections as well as ICMP connections are not blocked by the FortiEDR Collector.
- Isolation mode takes effect on any trial to establish a network session following isolation mode initiation.
- Connections, that have been established prior to device isolation, would remain intact. Same applies on Communication Control denial configuration changes.
- Note that both Isolation mode and Communication Control denial do not apply on incoming RDP connections and ICMP connections.
- Email notification will be sent for events but not for comm control events for isolated devices so long as playbook is set correctly and have customer check junk mail folder as well
- If FCS is enabled Isolation will wait for response from FCS in order to not isolate on event that FCS will mark as safe. In other words, isolation waits for FCS response.
Q&A:
Q: Can I say the behavior is similar to what we have in communication control policy today when a process meets a deny rules?
A: It is practically the same behavior, as isolated devices are being moved to a "deny all" mode in application control.
Q: Except all new connection will be blocked from outside and from the collectors?
A: Correct
Q: I have tested, because of the keep-alive, RDP and TeamViewer session to the endpoints are still accessible in isolation. Is this an expected behavior?
A: Yes, as stated above it refers only to new connections
Q: And for icmp ping as well, it is still allowed from and to the endpoints?
A: ICMP is allowed even in isolation mode. It came as an enhancement as IT/ITOPS requested not to take down ICMP and allow to differentiate NW problem from isolation related scenarios.
Q: Is the connection to core and aggregator already natively exempted from the isolation so the collectors can still connect?
A: Correct, the isolation doesn't refer to our platform. The Collectors are still available to FEDR platform.
|
