Out of Memory Error on Large Adhoc Report about nexpose-client HOT 11 CLOSED

@bk5115545 ... see if this addresses the issue with the larger files.

An example usage for grabbing the raw data is:

  config = AdhocReportConfig.new('audit-report', 'raw-xml-v2', site.id)
  report = config.generate(nsc, 3600, true)
  File.write("export-#{site.id}.xml", report)

If that works out, I'll keep it in there. Otherwise, I'll strip it out, as it adds complexity.

from nexpose-client.

It worked on a couple of reports however then this happened.

/home/<username>/.rvm/gems/ruby-2.1.5/gems/nexpose-0.9.0/lib/nexpose/api_request.rb:139:in `execute': NexposeAPI: Action failed: User requested raw XML response. Not parsing failures. (Nexpose::APIError)
        from /home/<username>/.rvm/gems/ruby-2.1.5/gems/nexpose-0.9.0/lib/nexpose/connection.rb:90:in `execute'
        from /home/<username>/.rvm/gems/ruby-2.1.5/gems/nexpose-0.9.0/lib/nexpose/report.rb:240:in `generate'
        from sample.rb:66:in `block in <main>'

Line 66 in sample.rb is the config.generate(...) call

from nexpose-client.

When that happens, you should be able to inspect the raw xml to see if there is an error in there. That error message should only happen because the response didn't contain the string 'success="1"' ... there may be a legitimate (non-Ruby) error in there.

You can view the raw response by inspecting it on the connection:

local_nexpose.response_xml

If you haven't made any further calls to the nexpose console, that will contain the ad hoc report response.

from nexpose-client.

While I'm waiting on the application to crash again so I can inspect the XML, I was looking through the scan log provided by the web gui. I found the below quite frequently.

2014-12-30T21:36:29 [INFO] [Thread: VulnerabilityCheckContext.performTests] [Site: <SITENAME>] [<target_ip>:443] apache-httpd-cve-2007-6388 (apache-httpd-cve-2007-6388-mod_status-open-redir-exploit13) - ERROR - (Enable verbose logging for more information): 
java.lang.NullPointerException
    at com.rapid7.nexpose.plugin.vulnck.ValueTest.matches(Unknown Source)
    at com.rapid7.nexpose.plugin.http.BaseHTTPCheckHandler$HTTPResponseTest.isHeaderMatch(Unknown Source)
    at com.rapid7.nexpose.plugin.http.BaseHTTPCheckHandler$HTTPResponseTest.isHeadersMatch(Unknown Source)
    at com.rapid7.nexpose.plugin.http.BaseHTTPCheckHandler$HTTPResponseTest.isMatch(Unknown Source)
    at com.rapid7.nexpose.plugin.http.BaseHTTPCheckHandler.getResponseMatch(Unknown Source)
    at com.rapid7.nexpose.plugin.http.HTTPCheckHandler$HTTPReqRespTest.isMatch(Unknown Source)
    at com.rapid7.nexpose.plugin.http.HTTPCheckHandler$HTTPCheckTest.performCheck(Unknown Source)
    at com.rapid7.nexpose.plugin.http.HTTPCheckHandler.handle(Unknown Source)
    at com.rapid7.nexpose.plugin.BaseCheckContext.invokeTest(Unknown Source)
    at com.rapid7.nexpose.nse.VulnerabilityCheckContext.performTests(Unknown Source)
    at com.rapid7.nexpose.nse.VulnerabilityCheckContext.performTests(Unknown Source)
    at sun.reflect.GeneratedMethodAccessor975.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.rapid7.thread.ThreadedCall.invokeCall(Unknown Source)
    at com.rapid7.thread.ThreadedCall.execute(Unknown Source)
    at com.rapid7.thread.ThreadedCallRunner.executeCall(Unknown Source)
    at com.rapid7.thread.ThreadedCallRunner.run(Unknown Source)

I know that it's not related to our changes with the gem but does this mean that the Nexpose console can't generate a report for sites with this error?

I also know that this error could have been caused by my team writing a faulty vuln check but we have never written our own vuln checks.

from nexpose-client.

It's hard to tell exactly what that stacktrace is. It could be harmless, but we'd have to have more context to really get to the heart of it (i.e., a support case with logs, etc.). It might show up in a report card with the "Unknown" status, if the check fully failed and couldn't continue.

Something in the scan log shouldn't affect what you are seeing in an export report, but there could be something about the data collected.

from nexpose-client.

Alright I have found the actual issue. The above stack trace isn't good but the issue was that there were too many connections to the Nexpose console internal postgres db and the db denied the connection request. It's in the logs on the Nexpose console and the timestamps nearly match. At that time, we had about 40 scans going on 40 different scan engines.

I'll just catch that exception and retry after a long delay.

The fix works great but some other issue got in the way of seeing it.

from nexpose-client.

OK. And, yeah, Nexpose (and the DB) will throttle activity if there's too much going on to protect itself. If you see something new, just reopen this issue or a new one. Thanks.

from nexpose-client.

As an aside, I am fairly certain that stack trace is hinting at a real, unrelated defect. I've filed it internally to get it tracked down (CONTENT-7079, internally)

from nexpose-client.

I just started getting this issue as well. I'm generating hundreds of ad hoc reports, is there a fix or do we just have some sort of timeout in between requests?

from nexpose-client.

@TheCaucasianAsian I tried adding a delay between my requests but it wasn't very effective. All my reports took varying times and a static delay didn't use the resources efficiently. I settled for the peach module, a wrapper around os.Popen to only download a few reports at a time. In my testing, I didn't see any performance improvement if I tried to generate more than 2 reports at a time.

If you use peach, be careful that all operations in the loop are completely independent of both previous iterations and variables outside the loop unless you want to add locking to a mostly single-threaded language. This is why I saved my reports in the loop ("unique_name.xml" was a computed name based on time and the sitename).

from nexpose-client.

Damn, right now I'm at the point where I just keep track of all the report names I try to generate, then loop back thru the directory to see which ones failed. I'm surprised this is still an issue. Thank you for the quick response I'll have to try out your suggestions!

from nexpose-client.