3 answers
- 10-1
Hi Jason,
You're not running with HTTPS only by chance?
HTTP must be enabled from localhost/127.0.0.1. This isn't a security issue as localhost traffic never hits an actual interface and therefore isn't prone to sniffing.
Mark U.
- 10-1
So a follow up, it appears the discoveries, while started, have frozen. I have 75,037 items in the queue table in my database, however it has been "stuck" not doing anything for over a day. I tried rebooting but it is not doing anything still. How do I clear this out gracefully? Trying to start a new discovery just adds it into the end of the queue...
Even while it was running, this new discovery process seems slower than the prior method.
- Mark Unwin
Jason,
To delete the queue items, run the below.
mysql -u openaudit -popenauditpassword openaudit -e "DELETE from queue;"
Are you running Open-AudIT on Windows or Linux?
Are you running the Discoveries from Community or Pro/Enterprise?
What size is your discovery (a /24, etc)?
The new process is an order of magnitude faster than the old. It runs truly parallel and you can increase or decrease the number of concurrently running processes.
After you clear the queue, try running the discovery again. If it fails to execute the queue (it may take a minute to start), call the below URL.
HTTP://YOUR_SERVER/open-audit/index.php/util/queue
This may hang your browser, so I'd suggest running it in an incognito window that won't affect your existing session. You should then be able to switch back to the original window, view the Discovery and see log entries being added.
Mark.
- Jason
Hi Mark,
I'm running community edition on Centos 7.7 and trying to discover multiple subnets of various sizes.
I cleared the queue following your directions.
I tried starting the discovery of a /22 again and nothing is being generated into the logs, nor do I see any change in cpu/memory utilization. I tried navigating to the URL and it is just a blank page. Running curl against the URL gives this:
> GET /open-audit/index.php/util/queue HTTP/1.1 > User-Agent: curl/7.29.0 > Host: XXXXXXXXXXXXXXXXXXXXXXXXXXX > Accept: */* > < HTTP/1.1 200 OK < Date: Mon, 18 May 2020 01:34:18 GMT < Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16 < X-Powered-By: PHP/5.4.16 < Content-Length: 0 < Content-Type: text/html; charset=UTF-8 < * Connection #0 to host XXXXXXXXXXXXXXXXXX left intact
What is really odd is that the Discovery "Started On" and "Completed On" dates are 2020-05-17 20:32:37 and 2020-05-17 20:32:38 respectively.
- Mark Unwin
Jason,
The cURL or browser request should basically return nothing, so your response is expected.
Discovery Started On and Completed On look normal. When we execute a discovery, we reset the Completed on to be after the started on. It will update itself when the discovery actually completes.
Nothing in the response is a worry. Started On and Completed On are being editied, so it looks like at least the initial request is working.
I'd take a look at the Apache error log at /var/log/httpd/error.log (a common place).
Check the logs at menu → Admin → Logs ( → System Logs in Community). If there has been a failure it should show there.
If you find nothing there, I'd set the configuration item "log_level" to 7, then re-run the discovery. Immediately after, set it back to 5. Then check the logs (menu → Admin → Logs). If you're using Enterprise or Professional the logs are nicely grouped by request and make it easy to see what happened. If you're using Community, you'll have to work through them manually.
- Jason
No matter what I did, nothing would be generated in the debug logs about discoveries other than accessing/viewing the pages for them.
I instead deleted all my discoveries and re-imported from csv. I've started one and it is now working. I'll see if it freezes up again.
One possible bug I found is that when I export my discovery list in this version, I get many lines of errors in the file above the actual lines of the discoveries that consist of
"<div style=""border:1px solid #990000;padding-left:20px;margin:0 0 10px 0;"">",,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,,
<h4>A PHP Error was encountered</h4>,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,,
<p>Severity: 4096</p>,,,,,,,,,,,,,,,,,,,,,,,,,,,
<p>Message: Object of class stdClass could not be converted to string</p>,,,,,,,,,,,,,,,,,,,,,,,,,,,
<p>Filename: helpers/output_helper.php</p>,,,,,,,,,,,,,,,,,,,,,,,,,,,
<p>Line Number: 418</p>,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,,
- Jason
90 minutes later and the discovery is still status "running."
The subnet I'm scanning is 10.84.4.0/22
The scan started at 8:45AM CDT and the last line in the logs for the scan is at 9:07AM CDT
2020-05-18 09:07:12 28658886 10.84.7.255 device complete IP Audit finish on device 10.84.7.255
Command:Peak Memory
Output: 82.954 MiBI'm unsure why it is scanning the broadcast address... It also says further up in the logs that the broadcast address is responding, which seem suspect.
2020-05-18 08:45:11 28614726 10.84.7.255 notice IP 10.84.7.255 responding, adding to device list.
I cannot ping it, nor does any port respond...
I see this at the beginning of the scan, which seems odd
2020-05-18 08:45:08 28613644 127.0.0.1 notice Retrieving IP list
Command:nmap -n -sL 10.84.4.0/22
Output: Total IPs: 10242020-05-18 08:45:08 28613645 127.0.0.1 notice Ping response not required, assuming all 1024 IP addresses are up. 2020-05-18 08:45:08 28613646 127.0.0.1 notice Testing for responding IPs
Command:nmap -n -sL 10.84.4.0/22
Output: Responding IPs: 10242020-05-18 08:45:08 28613647 127.0.0.1 notice Nmap response scanning completed. Shouldn't the test for responding IPs use -sn rather than -sL?
- Mark Unwin
Jason,
The exported discoveries issue has (now) been filed as a bug. This will be fixed for our next release. I will supply a patch if possible once it's sorted.
Scanning the broadcast address is an Nmap thing. We supply it the subnet and it discovers the IPs. You could use an IP range instead if you deliberately want to avoid scanning that particular IP.
The last Nmap scan using -sL is intended as you have specified that a ping response is not required. That's in the discovery scan options (configurable in Enterprise). If you're using Community, you'll need to change the global discovery_default_scan_option in the configuration to another that doesn't use that option. I always use Ultra Fast unless I have difficult devices on given IPs.
http://YOUR_SERVER/open-audit/index.php/configuration/discovery_default_scan_option
Are devices now being discovered?
- Jason
The discovery is still in status "running"
The setting is at ultrafast for all these discoveries and the default is ultrafast
The last log entry is still from over 24 hours ago.
- Mark Unwin
Jason,
Can you email the discovery support (see Open-AudIT Support Information) to marku@opmantek.com
I'll give it a look.
Mark.
- Jason
Hi. Unfortunately, I had to revert to the 3.2.2 snapshot as we needed to get it working again. I'll be sure to upgrade again in the future, see if I can replicate the issue, and try the discovery support option if it works in community edition.
Add your comment... - 10-1
Hello Jason,
Thank you for posting this inquiry. We have heard similar problems from other users, and are looking into this as high-priority.
Could you help us with a bit of testing? What version did you upgrade FROM, and what OS is this installed ON.
Best,
Mark H
- Jason
Hello, as already mentioned, I upgraded from 3.2.2
This is running on Centos 7.7
Add your comment...
Hello, I just upgraded from community edition 3.2.2 to 3.3.2 and now discoveries do not work. I even tried deleting one and recreating it, but nothing happens. It shows status as "running" but no processes change on the server, nothing is generated in any log files, nothing happens.
For now, I've reverted back to my snapshot from before the upgrade. Does anyone have any ideas for what I can look at?