search

microsoft / OMS-Agent-for-Linux

http://www.microsoft.com/oms
Other
411 stars 309 forks source link

Wrongly reported critical security issue "Zeroconf networking should be disabled." on Centos #843

Closed schweikert closed 2 months ago

schweikert commented 6 years ago

omsagent/omsbaseline is reporting a critical security issue on CentOS 7.4 machines: "Zeroconf networking should be disabled":

NAME | Zeroconf networking should be disabled.
CCEID | CCE-14054-1
RULE SEVERITY | Critical
FULL DESCRIPTION | Zeroconf networking should be disabled. (disabled)
POTENTIAL IMPACT | An attacker could use abuse this to gain information on network systems, or spoof DNS requests due to flaws in its trust model
ACTUAL VALUE | open /etc/network/interfaces: no such file or directory

As can be seen in "ACTUAL VALUE" , the check that is done doesn't work on CentOS/RHEL machines, because it assumes that the network configuration is done Debian/Ubuntu-style with /etc/network/interfaces. On CentOS I think that you should only check that the avahi-dnsconfd service is disabled (plus avahi-daemon, but that is checked already).

lonevvolf commented 5 years ago

Seconded - I am actually surprised that the check fails. As far as I can see, it is trying to confirm that there are no lines matching "ipv4ll" in the (missing) file /etc/network/interfaces. Shouldn't a missing file also pass the CheckNoMatchingLines test?

srice01 commented 5 years ago

If it helps, we are seeing this problem as well so it would be good if this issue was addressed as currently we are seeing "false positives" for this issue on all of our Azure VMs in Security Center.

pmdci commented 5 years ago

Same here. CentOS 7.6 having the same issue and the file /etc/network/interfaces doesn't exist. So...

bbaassssiiee commented 5 years ago

It is even more complicated! /etc/systconfig/network is changed by cloud-init. I ran my ansible playbook to disable zeroconf networking as per https://access.redhat.com/solutions/8627

- name: check presence of sysconfig network file
  stat:
    path: /etc/sysconfig/network
  register: sysconfig

- name: disable zeroconf networking
  when: sysconfig.stat.exists
  lineinfile:
    dest: /etc/sysconfig/network
    regexp: '^NOZEROCONF'
    line: 'NOZEROCONF=yes'
    state: present

But I found this file changed by an MS agent after a reboot:

cat /etc/sysconfig/network
# Created by cloud-init on instance boot automatically, do not edit.
#
NETWORKING=yes
dcskinner commented 4 years ago

This still looks like an issue. Wouldn't a better check be to look for the zeroconf route in the routing table?

andreleb commented 4 years ago

Hi all,

This is not an ideal solution but its a work around for me at the very least......

I had three servers reporting this issue for RHEL and the security team/Audit where on me about resolving it. even doh I showed them the zeroconf was in fact turned off they would always bring up Azure Security Center shows it as an issue.....

So I got creative.... I found out what Azure security Center was looking for witch was the file /etc/network/interfaces with the following entry in it NOZEROCONF=yes

I then simply created that file with the entry in it and the error went away in Azure security Center.

I also added the following entry NOZEROCONF=yes in the file /etc/sysconfig/network as well to cover my bases.

So that it is disabled and Azure Security Center also reports it as disabled.

UPDATE

This solution is a simpler work around to my original suggestion: instead of creating a file in /etc/network/interfaces with NOZEROCONF=yes in it, creating a symbolic link named /etc/network/interfaces to the /etc/sysconfig/network file with the NOZEROCONF=yes would be simpler since you would only have to maintain the flag in one spot....

The command that you would need to run for this would be

ln -sf /etc/sysconfig/network /etc/network/interfaces

END OF UPDATE

I know its not ideal but this post has been up for a 1 and 1/2 year and its still an issue at least this gives you a fighting chance with the security/audit overlords. :)

dcskinner commented 4 years ago

@andreleb good info. I found another and am wondering if you ran into the same. Security Center is complaining about system accounts (UID < 1000) able to login. If I look on my clean test box, the only accounts like that (other than root) are the 2 accounts that the OMS agent creates during install. Lovely...

andreleb commented 4 years ago

@dcskinner Yes I did this one I just had to shake my head, laugh and cry a little... then move on.... I Was not going to start messing with the user ID for OMSagent users to many tangibles.

Although I do think that this one was re-mediated since I see my agents has now an ID under 1000

pmdci commented 4 years ago

Where is MICROSOFT on this? Microsoft's lethargy on handling submitted issues doesn't give me any confidence.

dcskinner commented 4 years ago

@andreleb under 1000 is the problem. They should either be nologin or >1000.

dcskinner commented 4 years ago

So, omsagent for Azure Security Center is installed and appears to be working (mostly). Next on my list was to get SCOM monitoring working. It looks like that also uses omsagent. Has anyone gotten both SCOM and ASC monitoring the same Linux server? The omsagent from ASC appears to have installed keys that allows them to communicate. I'm assuming we need to add keys for SCOM?

andreleb commented 4 years ago

So, omsagent for Azure Security Center is installed and appears to be working (mostly). Next on my list was to get SCOM monitoring working. It looks like that also uses omsagent. Has anyone gotten both SCOM and ASC monitoring the same Linux server? The omsagent from ASC appears to have installed keys that allows them to communicate. I'm assuming we need to add keys for SCOM?

Good luck with SCOM I don't know much about it as it was not used by our UNIX team..

andreleb commented 4 years ago

Hi @dcskinner @schweikert @lonevvolf @srice01 @pmdci @bbaassssiiee

I hope all is well with you and your families during this time of world pandemic...

For anyone who is interested I found this link that actually list the .xml file for the logic behind the Azure Security Center - Linux Security Configuration.

https://github.com/microsoft/PowerShell-DSC-for-Linux/blob/master/Providers/Modules/Plugins/SecurityBaseline/plugin/oms_audits.xml

All you need to do is get the BaselineRuleId and then run a find on your browser of said BaselineRuleID

FOR EXAMPLE: To search for the Zeroconf networking should be disabled error the BaselineRuleID is 083550af-f4fe-4e1a-a304-dac894d58908

Searching for that entry this is what is showing up.

  description="Zeroconf networking should be disabled."
  msid="89"
  cceid="CCE-14054-1"
  severity="Critical"
  impact="An attacker could use abuse this to gain information on network systems, or spoof DNS requests due to flaws in its trust model"
  remediation="Remove any 'ipv4ll' entries in the file '/etc/network/interfaces'"
  ruleId="083550af-f4fe-4e1a-a304-dac894d58908">
  <check
    distro="*"
    command="CheckNoMatchingLines"
    regex="ipv4ll"
    path="/etc/network/interfaces"

With this information I can easily pinpoint that this logic has 2 discrepancies

Firstly It assumes every distro is using the /etc/network/interfaces file (Which is not correct)

Secondly Its not actually looking for the NOZEROCONF=yes as per the REDHAT ( https://access.redhat.com/solutions/8627 ) recommended fix.. It appears its looking to see if the config file has an ipv4ll entry in it.

For me performing the symbolic link fix I suggested in an earlier post fixed my security issue because my original config file does not have the entry ipv4ll in it so it "Fixed" the error but not because I added the NOZEROCONF=yes.

Anyways I hope this link can help all of you with getting compliant with Azure Security Center not just for this issue.

I have also tagged the 4 contributors from the link. Maybe one of them can point us to the correct information/Direction to get this resolved once and for all?

@nawolfin @taglines @morwn @bennyfar

To the 4 Contributors any help would be greatly appreciated!

Thanks in advance! Please stay safe! Andreleb

brownz11 commented 3 years ago

I was working on this today, and double checked the Rule definition.

This was fixed for the RHEL/CentOS family in https://github.com/microsoft/OMS-Agent-for-Linux/pull/1250

It now correctly looks at /etc/sysconfig/network and for the RedHat recommened "NOZEROCONFIG" stanza.

   <check
          distro="RedHat|CentOS"
          command="CheckMatchingLines"
          regex="^NOZEROCONF=\w+\s*$"
          path="/etc/sysconfig/network" />
srice01 commented 3 years ago

Wondering why I am still seeing it the "Security Center" recommendations? Perhaps need to retract and redeploy the agent?

hestolz commented 2 months ago

Thank you for your submission. As previously announced, the Log Analytics agent has been deprecated and has no support as of August 31, 2024. If you use the Log Analytics agent to ingest data to Azure Monitor, migrate now to the new Azure Monitor agent. As part of repo archival, open issues and pull requests will be closed.