Testing out XDR - Is This Thing On?
Finally got our XDR for MSP licenses enabled today and went to test them out. The XDR AD Integration was SUPER simple. We also wanted to deploy the XDR network sensor. We have multiple VLANs in our facility - two of which have Bitdefender Endpoints. So the docs weren't super clear on how to handle that situation. Would a secondary promiscuous virtual interface (eth2) be detected and monitored? Or was a 2nd virtual machine required? We played around with multiple promiscuous interfaces (eth2), but it didn't seem to get detected. So we spun up a 2nd XDR Network instance on our Hyper-V. Eventually we got this to work and both sensors are reporting in!
A couple observations and questions...
1) One of our instances was a PAIN to get working. The 2nd one showed up in the cloud console in a heartbeat. But the first one would not show up as an active device and those wasn't available for a sensor. Finally were able to figure out that for some reason that instance was causing eth0 to be promiscuous, not eth1. ifconfig in the terminal confirmed it. We had setup the 2nd Hyper-V interface as promiscuous in both instances. We even grabbed the vhd file again - started from scratch. Nope - it booted with the 1st adapter (eth0) as promiscuous (but the 2nd adapter was set that way in Hyper-V) So we set the 1st adapter in Hyper-V to promiscuous, matching what the linux image was doing (eth0) - and it showed up immediately with eth0 sensing and eth1 communicating. No clue why this happened, but may save someone else a lot of hassle. We weren't sure if it was blocking a 2nd sensor in the same company, etc. It's working great now
2) Would be REALLY nice if eventually we could have one instance monitoring multiple VLANs. But given how lightweight these things are, having an extra instance running isn't a huge deal.
3) Can confirm this works like a champ with VLANs. Set the instance's 2nd network adapter (promiscuous) to the virtual switch, with VLAN ID set, and Destination and it works great.
4) Given the isolation of modern switching - the XDR sensor isn't going to see much on it's own. Do the endpoints report network threat activity to the sensor as well (giving it much wider visibility). Or should the sensor's promiscuous interface be connected to a backbone mirror port if possible? Would there be any benefit to that or would it be too much load for not enough benefit? Or should it just be on a 'close as possible to the router' backbone switch?
5) It's not clear in the documentation - but the sensor auto detects the local relay and uses that without having to configure it. That's cool.
Once we got the instances up - ran Advanced IP Scanner and Incidents lit up like a Christmas Tree. VERY impressed so far and we just started playing with it.
Update - PLEASE give us even a notification only GravityZone Console app. But the ability to isolate, etc would be nice. No it doesn't need to be feature complete. Just the most common things an MSP might need to do like.. Isolate.
Also when you setup your sensor - it's almost an afterthought in the docs...
Incidents > Search section, by using the following query: alert.type:ghoster
To see if things are pinging like they should be. Also pay attention to the Date range - it has a time that sets to the moment you loaded the page, so you won't see new stuff unless you tweak it.
So I isolated an endpoint for fun and.. It's not intuitively obvious how to un-isolate it... Like.. I seriously haven't found how to remove the endpoint from isolation... You would think there would be some button in the Incidents -> Executed page but.. no. Maybe I need to resolve the whole incident? Hmmm
Found it!
(Sigh I can post an IMAGE because I'm too new?? You have to go to Network find the device. Check it. And under tasks 'Remove from Isolation'
Can we put that tip somewhere in the Incidents -> Executed view?
