The audit function of Open-AudIT is designed to work "out of the box" as much as possible with the default settings of target devices. Below are the requirements for the audit to work and some hints for items to configure when things are not working as planned.
Open-AudIT runs an Nmap discovery on each target IP address. Open-AudIT scans the Nmap top 1000 TCP ports, as well as UDP 62078 (Apple IOS) and UDP 161 (SNMP). For Open-AudIT to consider a target IP to have a device responding, any of the Nmap Top 1000 TCP Ports must be responding or the UDP 62078. A target that responds to UDP 161 (SNMP) only and NO other ports (TCP or UDP 62078 / 161) is not considered to be responding.
Why do we not consider a UDP port 161 response enough? Because it is very common for firewalls separating network segments to respond with UDP 161 for a target IP regardless of there being an actual device present at that IP address.
Why don't we simply scan every port TCP and UDP? On local networks this is usually OK to do, but on remote subnets this can take (literally) hours PER IP ADDRESS.
OA needs to see more than just UDP port 161 open on a device to consider it a legitimate device. If OA is only seeing UDP port 161 open OA will consider it a false positive and move on. If this is your situation you can edit the /usr/local/open-audit/other/discover_subnet.sh file and set consider_161_enough to “y" |
On Windows, Open-AudIT uses WMI via VBscript as it's primary method of auditing. SNMP is also supported (as detailed below). Windows has a notorious reputation where remote WMI is concerned. It tends to either "just work" or some mystery item on the target requires changing. If you are experiencing difficulty auditing remote Windows PCs, we have created a script called test_windows_client.vbs. You can run this script LOCALLY on the machine in question, after signing on as the user that is used by Open-AudIT to perform the audit. The script makes NO CHANGES to the target system. It checks most (not all) of the items below and generates PASS, FAIL and INFO tags for various properties. NOTE - If your target system is being audited correctly, you should not change any settings. Some of the below don't exist on Windows PCs that are able to be audited and some do exist. Only change settings if yours audits on particular PCs are not working as intended.
In addition to the below, other items that should be checked are the time between the client and the domain controller and that DNS is resolving correctly (both forwards and backward).
Some users have also stated that removing and then rejoining the client PC to the domain has enabled auditing to work.
Note - All commands below should be entered into an elevated command prompt. To do this click Start -> All Programs -> Accessories -> Command Prompt, right click then "Run as administrator".
Microsoft Article, Connecting to WMI Remotely Starting with Windows Vista - http://msdn.microsoft.com/en-us/library/aa822854(v=vs.85).aspx
Another good Microsoft article, https://msdn.microsoft.com/en-us/library/aa826699%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
To audit a machine, you must have credentials and administrator level access.
** NOTE - To enable a remote machine (Vista or above) to be audited that is not on a domain, by an account in the Administrators group, other than the actual Administrator account see the below section on UAC.
#1 NOTE - You can audit a remote machine without the using the actual Administrator account by creating a registry key. Create the below key on every machine to be audited and make sure the user credentials used are in the Administrators group.
\HKEY_USERS\.DEFAULT\Software\Microsoft\Windows Script\Settings |
Run the DCOM utility and verify (or set) the below attributes. Start -> Run, Enter DCOMCNFG and press OK. This will open the DCOMCNFG window.
Browse down the tree to Console Root -> Component Services -> Computers -> My Computer
Right click on "My Computer" and select properties
Select the "Default Properties" tab
Select the "COM Security" tab
Click on Access Permissions ' Edit Default
Click on Launch and Activation Permissions ' Edit Default
Click on OK and close the DCOMCNFG window.
The above changes will require a reboot to take effect.
If you are getting an Access Denied scan error it might be UAC blocking inbound requests on the remote device. If the remote computer you are trying to query is in a workgroup (or not joined to a domain), UAC prevents remote queries by default, even if the account being used is in the Administrators group. Completely disabling UAC on the remote device allows you to get around this, but it is preferable to disable the subcomponent of UAC instead. You can do this by adding or editing this registry key on the remote device you are scanning and setting its value to 1:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy
Note that Windows 8 and Server 2012 do not have a way to completely disable UAC (adjusting the slider in the GUI just disables notifications). You'll need to use the registry key method.
You can use this command from a command prompt on the remote device to quickly add the registry key:
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f |
Reference - https://support.microsoft.com/kb/942817
The above change will require a reboot to take effect.
Run one of the following three Microsoft Management Console (MMC) snap-ins:
Expand Security Settings -> Local Policies -> User Rights Assignment.
Check the Administrators Group has at least the following rights:
Go to Start -> Control Panel -> Administrative Tools -> Local Security Policy
Navigate to Security\Local Policies\Security Options
The above changes will require a reboot to take effect.
Windows XP Professional computers in a workgroup environment will need simple file sharing disabled. You can make this change through the registry by setting the following key to a value of 0.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ForceGuest
If this key does not exist, you can add it using a command prompt by:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa /v ForceGuest /t REG_DWORD /d 0 /f |
You can also do this through settings by performing the following steps:
Click Start → Control Panel → Folder Options.
Select the View tab and scroll to the bottom of the Advanced Settings: section.
Uncheck the Use simple file sharing (Recommended) to disable the option and click the OK button.
SSPI means Security Support Provider Interface and is the interface used by VBscript / WMI to validate the user.
The above changes will require a reboot to take effect.
Windows WMI (Windows Management Interface) is used by the audit script for most of it's information retrieval. WMI can (at times) become corrupted. Microsoft have released a tool to enable you to check for this corruption.
The tool is available from Microsoft, here - http://www.microsoft.com/en-au/download/details.aspx?id=7684
Using the tool is detailed here - http://blogs.technet.com/b/askperf/archive/2012/02/03/wmidiag-2-1-is-here.aspx
For Windows Core servers, ensure you allow the firewall connections as per - http://blogs.technet.com/b/brad_rutkowski/archive/2007/10/22/unable-to-remotely-manage-a-server-core-machine-mmc-wmi-device-manager.aspx
Some antivirus programs have been known to disable DCOM and remote WMI. You might check the settings of your antivirus program and disable them for testing. We recently had a report of Trend AV specifically blocking calls to winexesvc when auditing Windows computers.
To enable remote PCs to be audited, either the local (on the target machines) firewall (likely the Windows Firewall) must be disabled or access allowed for the WMI service.
For Windows Vista, 7, 8, 2008 and 2012, enter the following commands:
netsh firewall set service type=remoteadmin mode=enable netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes netsh advfirewall firewall set rule group="remote administration" new enable=yes netsh advfirewall firewall set rule name="File and Printer Sharing (Echo Request - ICMPv4-In)" new enable=yes |
On Linux, Open-AudIT uses SSH as it's primary method of auditing. SNMP is also supported (and detailed below).
The user used to audit a Linux host should be root or have sudo access. Some distributions do not allow sudo over an SSH session without a terminal. On these distributions, root can be used.
Using a user account that has no sudo access (and is not root) will result in an audit without all possible attributes retrieved.
Sudo / Root is required for:
dmidecode
(system - uuid, serial, form_factor),
(bios - version, smversion, serial),
(processor - socket),
(memory - all)
netstat
(netstat - program name where not owned by user running script)
NOTE - Running as different users will generate a different list of environment variables.
If you find your target machine is not correctly being audited, check to make sure SSHGuard has not been triggered. Below you can see the IP 192.168.1.179 has been blocked by SSHGuard (see last line).
root@desktop:/# iptables -L -n -v Chain INPUT (policy ACCEPT 77217 packets, 48M bytes) pkts bytes target prot opt in out source destination 35M 43G sshguard all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 77202 packets, 48M bytes) pkts bytes target prot opt in out source destination Chain sshguard (1 references) pkts bytes target prot opt in out source destination 77 6368 DROP all -- * * 192.168.1.179 0.0.0.0/0 |
To enable your Open-AudIT server, edit the file /etc/sshguard/whitelist and restart the sshguard service.
sudo nano /etc/sshguard/whitelist sudo service sshguard restart |
On VMware ESX, Open-AudIT uses SSH as it's primary method of auditing. SNMP is also supported (and detailed below).
On OSX, Open-AudIT uses SSH as it's primary method of auditing. SNMP is also supported (and detailed below).
The OSX audit script should be run by root or using sudo access.
On AIX, Open-AudIT uses SSH as it's primary method of auditing. SNMP is also supported (and detailed below).
The AIX audit script should be run by root.
On Solaris, Open-AudIT uses SSH as it's primary method of auditing. SNMP is also supported (and detailed below).
The Solaris audit script should be run by root.
SNMP v1, v2c and v3 are supported. Read access is required.