Improvements on Network scanning and Scan Uploading

[rongutierrez]

It looks like you only allow a single IP address when performing Network scans. This won't scale much at all..

Additionally, when a new Network project is created and a nessus scan is uploaded all of the findings within the Nessus scan would be associated with the target ip used whenthe scan project was created instead of the actually reported IPs within the Nessus scan results. In general, I have the following proposals for making this a better solution

• Support multiple targets, since scans are typically run against multiple IPs

• Decouple Scan Projects and targets from the scanner uploads. Having to create a new scan project and specify a target before you can upload a scan result is a awkward workflow and doesn't scale.

• The ingested results should be tied to the IPs addresses reported within the uploaded results and not to the predefined target IP address when the project was created. Networks scans will likely always be run against multiple targets.

• Expose scan uploads as a API call. I envision this tool being useful in existing CI infrastructures that already have code, app and network scanning in place. Jackhammer has a lot of value in being a central location to view the results and manage vulnerability triaging.

[roelstorms]

Managing network targets as mentioned above via ranges (look an nmap for a good synthax to support)

Also, from this infra scan the ability to define the service running on the port and have service specific scanners that can be launched at the click of a button. You scan 192.168.1.0-255 and have 10 hosts with port 80 open. Then you want to launch a web app scan on these hosts automatically.

Love the project btw!

[shadsidd]

@rongutierrez completely agreed with you and WIP on that. The V2 of jackhammer would solve the shortcomings you mentioned and provide tons of additional feature across all kind of scanner with support for docker scanning. It would also have tools segregated so anyone could modify tools without causing a problem to any other tool and the single orchestrator will take care of self-healing and rolling back in case there is a problem. Your current feature request are not major to fix but I would request you to hold on for a couple of weeks for the V2 that would be a major bump to the current architecture .

@roelstorms As I mentioned above the V2 would run all the scan in parallel and we wont need Owasp Pipeline and it would have feature to upload files containing list of ips, mass-scanning etc. And Reporting format would be revamped a bit for better showcasing of results.

Hope that helps :)