This is often an overlooked crucial step for endpoint protection software. Sometimes EPP can have buggy code or crash after windows updates/reboots.
Example 1.
I use PDQInventory to scan endpoints EPP service status hourly and drop them in a dynamic group. These two endpoints in particular had Windows updates installed and rebooted. To confirm I can use powershell Win-RM to get the status of the “sentinelagent”
This means my endpoints are unprotected from malicious code. To start them again I can pipe in | start-service command.
Example 2.
Code bug I discovered and reported affecting versions prior to 23.4. I utilize the host based firewall control via SentinelOne and scan my agents. I block RPC, NetBIOS, SMB, RDP, etc inbound. In the screen shot you can see me sweeping subnets looking for TCP 445 open. If the endpoint has this port open I know there is a problem with SentinelOne on that machine.
In this screenshot you can see all these ports open. So, we have a problem.
To confirm, I will login to the management console and review the machine. I can see that it is offline to the S1 console, but is online. Firewall status shows as enabled. Let’s look further…
I RDP to the endpoint and look at the UI. The managment console URL has switched to localhost??? What the hell? I use location based firewall rules. So, this would make the rules not apply. Looking through the documentation.
.If I issue the \SentinelCtl.exe bind site token -k “Passphrase” cmd it will rebind to my management console.
After rebinding the endpoint was fixed and was blocking inbound traffic again.