Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run OpenVAS scans via OSP instead of OTP #422

Merged
merged 26 commits into from
Jun 7, 2019

Conversation

timopollmeier
Copy link
Member

This new scanner type uses OpenVAS scan configs and connects to an OSP
scanner (ospd-openvas).

This new scanner type uses OpenVAS scan configs and connects to an OSP
scanner (ospd-openvas).
@timopollmeier timopollmeier self-assigned this Mar 12, 2019
OSP expects boolean preferences to be 1 or 0 instead of "yes" or "no"
and only the selected value for selection preferences.
@bjoernricks
Copy link
Contributor

Do we really need an extra scanner type? Isn't it just an OSP scanner?

Without this OSP tasks had to wait until the end of the scan before
fetching any results, which could take a long time for scanners like
the OpenVAS one and tasks with many target hosts.
This parses results with the "general/Host_Details" port as host details
as it is done in OTP.
This should eventually be handled by the "Host Detail" result type once
there is a well-defined way to handle the source info in OSP.
The credentials for OSP scans are adjusted for the change in gvm-libs to
use the new method of storing the authentication data like username
and password.
This allows using SSH private key authentication in OSPd-OpenVAS scans.
The osp_scanner_connect function will no longer try to get the port,
ca_pub, key_pub and key_priv from the scanner as they are not needed
and getting the private key could fail if the scanner has no credential.
OSP results with "HOST_START" and "HOST_END" as NVT id will be used to
set the start and end time of a host.
The parse_osp_report() function will now get the hostname attribute from
OSP results and make_osp_result() will store it in the results table.
@timopollmeier timopollmeier marked this pull request as ready for review May 29, 2019 07:01
@timopollmeier timopollmeier requested a review from a team May 29, 2019 07:01
Copy link
Contributor

@mattmundell mattmundell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, waiting to see about gvm-libs changes.

src/manage_sql.c Outdated
g_warning ("%s: Failed to add report detail for host '%s': %s",
__FUNCTION__,
host,
desc);
}
else if (host && nvt_id && desc && (strcmp (nvt_id, "HOST_START") == 0))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a strange feature of OSP.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think it would be a good idea to change this. How would you handle the host start and end times in OSP?
My suggestion would be to add a new host detail result type to OSP and use "host_start" and "host_end" as the names.
I'm not sure if we should do it in this PR already.

mattmundell and others added 5 commits May 30, 2019 16:47
The OSP-OpenVAS scanner type is removed again in favor of running all
OpenVAS scans via OSP instead of OTP.
The process running the function may not have global_current_report set,
so the current report has to be fetched from the task.
@timopollmeier timopollmeier changed the title Add scanner type "OSP-OpenVAS" Run OpenVAS scans via OSP instead of OTP Jun 5, 2019
The osp_start_scan_ext function has been changed to have most options
passed in as a new struct type (osp_start_scan_opts_t).
The osp_scanner_connect function will now log a warning message
containing the hostname or socket path.
The variables start_time and end_time in the parse_osp_report function
and rc in the handle_osp_scan function were not initialized.
@mattmundell mattmundell merged commit d387c06 into greenbone:master Jun 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants