![]() The more log sources you have for an investigation or threat hunt, the more you might accomplish. It certainly looks a bit suspicious, so this is something I’ll need to hunt from my internal network to figure out if it’s a valid or invalid query.Ī quick look into my Unifi dashboard reveals that I have a wireless client, that fits the MAC address (that I’ve blurred out above).Log collection is critical to a successful security analytics program. Here’s a sample from timed out DNS requests in my internal network:Īpparently, there is a device – of type U7HD, trying to query for DNS zone. Once you start getting results, you can drill down by selecting a query, and viewing the results. Once enabled (and this partially confirms your logs are in place, otherwise the enable will fail), you can go to Azure Sentinel > Hunting, and again search for Ubiquiti and select Run selected queries for all of them: Select all, and click Enable: Step 5: Hunting for suspicious activity Looks promising! Now, go to Azure Sentinel > Analytics, and search for Ubiquiti. Open the Log Analytics Workspace in Azure Portal, select Logs and query for Ubiquiti_CL: And the OMS Agent is pushing those logs to Azure Sentinel’s Log Analytics Workspace. Your Unifi controller (Cloud Key, Cloud Key Gen 2, UDM-Pro) is sending logs to your Linux VM. You have a Linux VM with the OMS Agent running. The infrastructure configuration is now complete. Step 4: Verifying that logs are visible in your Log Analytics Workspace If you made a typo in your nf, then the logs will tell you that the omsagent instance could not bind to the port you’ve selected. Now, within /var/opt/microsoft/omsagent/log you can tail omsagent.log to see if your messages are being sent properly.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |