I can’t get the output of the log_message() invocation in nmap.nasl that is supposed to communicate the arguments of nmap invocation (in a message starting with "nmap command: ", line 380 in GSE version 21.04)
Just in case, - I already twisted the settings in /etc/openvas (“log_whole_attack = yes” in openvas.conf, log_level=128 everywhere in openvas_log.conf) but that did not produce the desired information.
Neither I can run the nmap.nasl script using stand-alone openvas-nasl - as I do not know how to communicate in this case all the “preferences” read, apparently, through script_add_preference(). In any case, running nmap.nasl using the openvas-nasl driver terminates prematurely.
I started peaking inside the scanner implementation (openvas-scanner-21.4.3/nasl/nasl_scanner_glue.c and so on) and see that there is some sort of messaging protocol - how is then that configured??
There is a scan configuration parameter (not a scanner preference) of that specific VT which is called “Log nmap output” and which needs to be set to “yes” in your scan configuration so that the nmap output will be shown.
… thanks!!, but that parameter has already been set to ‘yes’ (I peeked inside the script, of course); I apologize - I should have mentioned this from the outset. Maybe question is rather where exactly it “will be shown”; it does not seem to appear in the /var/log/gvm. Maybe it also matters that I run the ‘GSE’ version; both a pre-built docker image (by ‘immaus’ (spelling?)) and built from sources by myself - all running on some Ubuntu 20.04
Then I built a ‘Debug’ version of the openvas binaries and libraries and used gdb to trace nmap.nasl’s execution - as run within the GVM eco-system (attach’ing to gvm-forked processes, with some sleep(30) kludges to gain enough time to pull off the attaching :-)); I believe I got to the point where the aforementioned parameter is read as ‘yes’ but then, frankly, lost the track - and I did not have the time to figure out (nor found information about) how to trace/debug execution of the nasl scripts, BUT I did not observe the log_message() library function actually called (I had a breakpoint on it).
Logging script execution (and tracing/debugging the openvas binaries) should be a simple “RTFM” matter; it does not seem right to spend time to reverse-engineer the logging & tracing & debugging of these scripts, does it? Hence was my question here.
All output of VTs done by either security_message() or log_messge() will end up directly in the scan report of the VT calling these functions. For log_message() output the filter within the scan report needs to be adjusted to show Log level results.
… thanks!, now I got the desired information. The only caveat was that the report level ‘log’ is activated with "level=g’, not “level=l”. Still, it helped that the default ‘level=hml’ report did include the “Issues with the threat level Log are not shown.”; otherwise it’d be tricky to understand what’s going on.
Also, when we came to that - I believe the GSA’s “/report” GUI web page [where reports can be downloaded] has a little bit convoluted: when one clicks the ‘Download filtered Report’ button (icon with an arrow pointing down) then one can’t edit the filter there; instead one needs to copy the existing filter to the clipboard, then ‘cancel’ the download pop-up, and then paste the filter into the ‘Filter’ form field and modify it (and the repeat the downloading)
All in all, - thanks, the (immediate) problem is solved!