I am looking for best practices for scanning Macs for vulnerabilities. Any help would be appreciated.
There's TWO things you need to do.
1) Change the tracking method to IP
2) Enable agentless tracking on the authentication record
This will allow the asset to be tracked by the GUID instead of the IP without relying on the PTR record.
However, there is a rub. What you do not want to do is change the IP's one by one, you need to change the DHCP scope as block. See this article.
So, if the DHCP scope is shared by other things such as Windows endpoints, make sure you enable agentless tracking on their authentication records also.
We have about 200 Mac's in our environment. Initially they implemented using a local account on every system to authenticate. I found this ineffective once I took over because Auth Record Report showed there was no setting or improper configuration for the sudoers file.
My new plan is to use SSH keys and a domain account. SSH keys can be updated/pushed out by the Linux admin's or installed at the time of the build. The domain account allows for password cycling to stay within enterprise standards. The hardest part is going to be ensuring the sudoers file is properly configured.
I plan to use this practice for our MacOS users as well as our servers across the entire enterprise.
You could also look at the option of deploying the Qualys CloudAgent for MAC. This is way more simpler and needs least or no management.
I'd love to. Unfortunately the CA w/VM isn't a part of the Consultant offering.
Thanks Red Beard. I like the domain keys approach for express. I'll probably stick to SSH when we do assessments for our clients.
Should I add anything extra in Option Profile to scan Macs, authenticated or non-authenticated scans. TCP port or something? At the moment I believe I don't see any DNS Hostname, NetBIOS Name nor OS for Macs for scanned Asset Group.
Nothing specific needs to be added to scan Mac devices. The scanning engine is intelligent to detect the target as a Mac device and fire audits that are applicable to Mac's.
If you'd like scans to be authenticated, enable authentication within the option profile: Scans > Option Profiles > Scan > Authentication > Enable Unix
Also, make sure you've created the required authentication records: Scans > Authentication > New > Unix Record.
Is it possible from client side to set up local machine settings to not allow perform Qualys scans?
I would believe that you could restrict to a certain extent. If the host has a local firewall/host IDS, it could certainly block scan traffic.
However, there are going to be some ports that will be open and the scanner could perform some audits on them.
How can I have an authentication record for MacOS users when I am required to use a Unix Authentication Record and provide IPs? Mac's are laptops that receive DHCP addresses. Putting an agent on the host is not an option.
You could put in a range that reflects the DHCP scope.
how is everyone tracking Mac's when you cannot use the cloud agent? We track workstations via DNS, our Macs are using cert auth for VM scanning but Qualys is failing because it cannot find a DNS record for the Mac apparently. Qualys support said to change tracking type to IP which is not ideal since Mac users change IP network segments numerous times a day/week from wired, wireless and vpn etc.
Change the tracking method of every Mac to IP? each Mac could be 10 different IPs today. We scan large segments which encompass Windows OS's, RHEL, various Linux and networking appliances.
agentless tracking is enabled across all records and always has been.
No, change the entire dhcp scope as one block. Read the referenced article it will make things a lot more clear about how to change tracking types and why.
my understanding after re-reading that article is that I can set entire netblocks as IP tracked, set authentication records to enable agentless tracking, scan the segments multiple times throughout the day and not have issues with duplication of assets or findings being mapped to to the wrong asset?
Correct. As long as authentication is working correctly.
For multi-homed assets like some servers, for example old fashioned web servers, authentication will happen on each nic and all nics will be collapsed down onto the IP of the last NIC authenticated against. Since the order of assets being scanned is not predictable this can cause IPs to move around even for assets that are static but multi-homed. For that reason this is not usually the best option for servers, but they tend not to be DHCP anyway. For endpoints this is rarely an issue.
i appreciate the information. we will test this out.
Retrieving data ...