We have really good license coverage in the Innovations Team that I am part of and recently we had Microsoft 365 Defender reporting high exposure on two linux servers. In our case these were two syslog forwarders that we use to give Sentinel visibility of our FortiGate virtual appliances. We use the latter to offer services to IaaS workloads hosted in Azure.

Looking at the device specific recommendations it told us “Update Microsoft omsagent for Linux”. My immediate reaction was to log on to each server and run the only command I know:

sudo yum update

This was fine on one server, the other had run out of space. To cut a long story short, I found that a couple of Azure VM Extensions had failed to install and in complaint were filling the boot disk with logs. I removed the offending extensions and this got space back.

Unfortunately the update made no difference. I’ll clarify what my goal was here; to get the security recommendation in Microsoft 365 Defender to go away. This is a process that can take some days depending on the update cycle between the enrolled Linux Machine and the process that generates the security recommendations. Short story – updating the server did not remove the recommendation to Update Microsoft omsagent for Linux.

So I went hunting for more specific instructions and found information on the Log Analytics agent (aha, so that is what omsagent is!) documentation page on upgrading the Linux agent. This directed me to run the following command (per documentation on 29th March 2022):

sudo sh ./omsagent-*.universal.x64.sh --upgrade

I tried this on both servers, in one case it could not find the script, in the other it appeared to run fine but exited with status 0 (I didn’t know if this was good or bad). It turned out that the script location was different on the two servers and I found the script in a different place. It ran in a similar fashion with a big long list out output and status 0 (still none the wiser).

I checked in again and Microsoft 365 Defender still recommended that we Update Microsoft omsagent for Linux.

So I had a think, and got rid of some of my Linux related caution (I’m not a confident Linux admin) and found myself at the home / source of the agent in GitHub. By this time I had a few tabs open in Edge and I did some command modification to get some context. I ran the following:

rpm -qa | grep omsagent

And the output of this suggested returned omsagent-1.13.35-0.x86_64 which I took to mean I was looking at a server with v1.13.35 whereas at the time of writing, GitHub had a latest release of v1.14.9 . So running the command above had not upgraded to the latest version. So I had assumed incorrectly, my hypothesis then became that I need to run the latest version in upgrade mode, rather than that an older version would automatically update itself to the latest.

So working through the readme on the omsagent for Linux GitHub page I copied the URL for the latest OMS Agent for Linux (64-bit) and ran this with the wget command to download the script i.e.

wget https://github.com/microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_v1.14.9-0/omsagent-1.14.9-0.universal.x64.sh

Then I ran the new version that I had just downloaded with the upgrade switch thus:

sudo sh omsagent-1.14.9-0.universal.x64.sh --upgrade

This produced an even longer output with lots of messages. When I checked Microsoft 365 Defender that recommendation had been removed for the two syslog servers in question. Job Done!

Epilogue

What I also found out is that the upgrade scenarios for the Log Analytics Agent are interesting and there is interaction with extensions etc. Azure Virtual Machine Extensions also have a short list of very specific events that trigger an upgrade (if the setting is available and set) and that this list is quite small and fairly rare (e.g. sku changes). The choices now available for vulnerability scanning get better each day, in my case following through on those recommendations for Linux can be tricky!