Skip to end of banner
Go to start of banner

Troubleshooting

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 24 Next »


The device discovery and auditing function of Open-AudIT is designed to work "out of the box" as much as possible with the default settings. However, each user's environment is different and sometimes adjustments to Open-AudIT's configuration, network security settings, or credential sets need to be completed in order for accurate audits to complete.

This guide will walk you through troubleshooting the most common problems reported by Open-AudIT users.

Problems Starting Your First Audit

If you are having trouble getting your first audit started, it is best to attempt to audit a single, known machine with proper credentials before moving on to full subnets of devices. Start with this guide below on how to audit a single machine.

First, make sure you've configured your devices properly: Target Client Configuration

Next, disable Blessed Subnets to test if this security feature is inhibiting the audit from running or adding a device to the dB: Blessed Subnets

Finally, run a discovery on a single device (not on a subnet) to help identify and focus troubleshooting efforts: How to discover a single Device


Limited Data Returning From Audit

Step 1 - First, determine if a detailed audit is being completed or only the initial results of the NMAP scan. The easiest way to do this is to run a Device report; select Report -> Hardware -> Device from the Open-AudIT menu, then select the device by clicking the blue View button in the left-hand column of the report. This will display the Device Details screen.

Step 2 - Now, click Details from the menu on the left under Summary. This will open the Details on the right side under the Summary panel. You should look for the Last Seen By field, depending on the version of Open-AudIT and type of device this may include NMAP, SNMP, or Audit. If it says NMAP, as the screen shot below, then a full audit has not been completed on this device. The next steps is to determine required ports are open, then if any of the supplied credential set(s) were accepted by the device.

 

Step 3 - Before continuing you should increase the log-level and rerun the audit on the device. This will give you in-depth debugging information that will help you determine exactly what went wrong during the audit. To adjust the log_level select Admin -> Configuration -> All from the Open-AudIT menu. Find the entry for log_level, which defaults to 5, and increase it to 7. This change will take effect immediately and detailed debug information will be captured during the next audit.

Step 4 - Now that you have adjusted the log_level to 7 and re-run an audit on the device you need to check the Discovery Log to see what happened. First, return to the Device Details screen as you did in Step 1 above. Then, select Discovery Log from the menu on the left. The discovery log, along with other logs and information open up below the Summary panel.

As shown in the image above, this example is using SSH credential set. SSH is typically used on Linux devices, WMI is used by Windows machines, and SNMP is used for network devices, Linux and Windows devices. More information on credentials and configuration can be found here: Target Client Configuration. The first underline in the image above is showing that SSH Status suggesting the SSH port is open. Notice WMI Status is shown as false as well as SNMP, if a device was using those forms of credentials then the Status should be true.

Ensure which ever credential type you are using is displaying the Status as true, otherwise the audit will not successfully complete. The second underlined part of this image is confirming that the credential set is working for this device and then continues below to show that the SSH audit is starting. Check the discovery log for this information after auditing your device to see if the credentials are being accepted with no issues.

Step 5 - What if you've done all this and the audit just never seems to find a device at an IP address you know is legitimate?

Open-AudIT runs an Nmap discovery on each target IP address. Ope-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.

UDP port 161 Workaround

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"


Duplicate Devices, Missing Devices, and Devices Being Overwritten

When Open-AudIT receives data about a device, either by discovering the device during an audit run or by the user importing the device, it must determine if this discovered device matches a device that already exists within its database, or if it is a new device that should be added. Open-AudIT uses a series of twelve property matches to determine this.

It is important to note that when Open-AudIT determines a match ALL properties set to 'y' must match exactly in order for Open-AudIT to determine that the discovered device matches a device already in the database. If any of these properties do not match, then a new device entry will be created, which could result in duplicate device entries. In situations where properties are duplicated, for example a dbus_id is copied during a VM clone, then an existing device may incorrectly get overwritten/updated rather then a new entry being created resulting in missing devices.

Guides for adjusting the matching rules are covered in detail HERE: Matching Devices


Discovery Stopped Working

If you are running a RedHat or CentOS system and you have upgraded Nmap or went to a previous version sometimes it is necessary to reset the SUID on the binary. You can do this by running the following command:

chmod u+s /usr/bin/nmap


User attempted to view a resource which does not exist error

This typically occurs when discovering a single device and the discovery completes and you click the refresh button on the page. When completing the  discovery the discovery itself may be gone which causes this error but the information gained from it should still be there. You can either search for the device within Open-AudIT or check out the discovery logs if you can't find it in the Open-AudIT GUI. To check the discovery logs in Open-AudIT navigate to menu -> Admin -> Database -> List Tables and look for discovery_log and click the blue details icon next to it. At this point export the file to CSV and should be able to find your device entry there.

  • No labels