Re: [Openvas-discuss] log_whole_attack = yes logs nothing

[Christian Fischer]

Hi,

On 10.11.2016 14:07, Fmy Oen wrote:
> 2016-11-10 14:16 GMT+02:00 Christian Fischer  net>:
> 
>> log_whole_attack is only logging the following into your
>> openvassd.messages:
>>
> 
> Well, here is what I try to understand: how can I find the reason of error
> status of the scan?
> 
> More specifically, how can I catch any output from nasl script? For example
> if debug_print in http://plugins.openvas.org/nasl.php?oid=11801 emits
> something, how can I catch it? My assumption is that it should appear in
> the file set by dumpfile option:

this debug_print will appear in your openvasmd once you're raising the
"Debug level" within the "Global variable settings" of your Scan
configuration.

Regards,

-- 

Christian Fischer | PGP Key: 0x54F3CE5B76C597AD
Greenbone Networks GmbH | http://greenbone.net
Neuer Graben 17, 49074 Osnabrück, Germany | AG Osnabrück, HR B 202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] log_whole_attack = yes logs nothing

[Fmy Oen]

2016-11-10 14:16 GMT+02:00 Christian Fischer :

> log_whole_attack is only logging the following into your
> openvassd.messages:
>

Well, here is what I try to understand: how can I find the reason of error
status of the scan?

More specifically, how can I catch any output from nasl script? For example
if debug_print in http://plugins.openvas.org/nasl.php?oid=11801 emits
something, how can I catch it? My assumption is that it should appear in
the file set by dumpfile option:

> dumpfile
> Some  plugins  might  issue  messages, most of the time to inform you
that something went wrong. If you want to read these messages, set this
value to a given file name. If you want to save space, set this option
value to /dev/null

Is my assumption correct?

Also it's unclear to me of how verbose regular output to the dumpfile is.
Is that a normal situation when several 'Full and fast ultimate' scans
result in literally couple of lines in the dumpfile?

> pcap_compile: syntax error
> pcap_compile: syntax error
> pcap_compile: syntax error
> pcap_compile: syntax error
> pcap_compile: syntax error
> pcap_compile: syntax error
> pcap_compile: unknown host 'addr'
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] log_whole_attack = yes logs nothing

[Christian Fischer]

Hi,

On 10.11.2016 13:09, Fmy Oen wrote:
> So far /var/log/openvas/openvassd.dump is empty after scan finish. Any
> ideas?

log_whole_attack is only logging the following into your openvassd.messages:

> log_whole_attack
> If  this  option  is set to 'yes', openvassd will store the name, pid,
date and target of each plugin launched. This is helpful for monitoring
and debugging purpose, however this option might make openvassd fill
your disk rather quickly.

-> man openvassd

Regards,

-- 

Christian Fischer | PGP Key: 0x54F3CE5B76C597AD
Greenbone Networks GmbH | http://greenbone.net
Neuer Graben 17, 49074 Osnabrück, Germany | AG Osnabrück, HR B 202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] log_whole_attack = yes logs nothing

[Fmy Oen]

2016-11-09 17:50 GMT+02:00 Fmy Oen :

> Thanks, now openvassd.log is much more verbose. Will log_whole_attack help
> with the dumpfile output as well? 10 minutes passed since Full and fast
> ultimate task start, but dumpfile is still empty.
>

So far /var/log/openvas/openvassd.dump is empty after scan finish. Any
ideas?
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] log_whole_attack = yes logs nothing

[Fmy Oen]

2016-11-09 15:54 GMT+02:00 Christian Fischer <
christian.fisc...@greenbone.net>:

> the "log_whole_attack" needs to be set in your scan config within your
> GSA as a default "full'n'fast" config would overwrite the setting
> configured in your openvassd.conf.
>

Thanks, now openvassd.log is much more verbose. Will log_whole_attack help
with the dumpfile output as well? 10 minutes passed since Full and fast
ultimate task start, but dumpfile is still empty.
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] log_whole_attack = yes logs nothing

[Christian Fischer]

Hi,

On 09.11.2016 14:34, Fmy Oen wrote:
> I've set log_whole_attack and dumpfile options in openvassd.conf:

the "log_whole_attack" needs to be set in your scan config within your
GSA as a default "full'n'fast" config would overwrite the setting
configured in your openvassd.conf.

Regards,

-- 

Christian Fischer | PGP Key: 0x54F3CE5B76C597AD
Greenbone Networks GmbH | http://greenbone.net
Neuer Graben 17, 49074 Osnabrück, Germany | AG Osnabrück, HR B 202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

[Openvas-discuss] log_whole_attack = yes logs nothing

[Fmy Oen]

Hi, I'm having problems with a certain host scan ending with the error
status. In attempt to understand the cause of error I've set
log_whole_attack and dumpfile options in openvassd.conf:

# Log file (or 'syslog') :
logfile = /var/log/openvas/openvassd.log

# Shall we log every details of the attack ? (disk intensive)
log_whole_attack = yes

# Log the name of the plugins that are loaded by the server ?
log_plugins_name_at_load = no

# Dump file for debugging output, use `-' for stdout
dumpfile = /var/log/openvas/openvassd.dump

Despite that /var/log/openvas/openvassd.log looks like this for the whole
scan (both successful and faulty one):

[Tue Nov  8 15:23:38 2016][13391] Testing somesite.com (X.X.X.X) [13614]
[Tue Nov  8 18:46:56 2016][16370] open_sock_tcp: X.X.X.X:445 time-out.
[Tue Nov  8 18:47:57 2016][17617] open_sock_tcp: X.X.X.X:23 time-out.
[Tue Nov  8 18:48:10 2016][17865] open_sock_tcp: X.X.X.X:23 time-out.
[Tue Nov  8 18:48:38 2016][18601] open_sock_tcp: X.X.X.X:445 time-out.
[Tue Nov  8 18:48:48 2016][18601] open_sock_tcp: X.X.X.X:445 time-out.
[Tue Nov  8 18:51:30 2016][22492] open_sock_tcp: X.X.X.X:5001 time-out.
[Tue Nov  8 18:52:12 2016][23076] open_sock_tcp: X.X.X.X:23 time-out.
[Tue Nov  8 18:53:13 2016][23936] open_sock_tcp: X.X.X.X:515 time-out.
[Tue Nov  8 18:53:21 2016][24039] open_sock_tcp: X.X.X.X:10443 time-out.
[Tue Nov  8 18:54:11 2016][24271] open_sock_tcp: X.X.X.X:1804 time-out.
[Tue Nov  8 18:54:48 2016][24384] open_sock_tcp: X.X.X.X:7800 time-out.
[Tue Nov  8 18:59:09 2016][13614] Finished testing X.X.X.X. Time : 12931.24
secs
[Tue Nov  8 18:59:09 2016][13391] Test complete
[Tue Nov  8 18:59:09 2016][13391] Total time to scan all hosts : 13000
seconds

Dump file is empty. OpenVAS successfully creates it but writes nothing
since then.

Is that an intended behaivior? Any suggestions what can be done to enable
verbose logging?

Here is some information about my setup:

# uname -a
Linux ... 2.6.32-642.6.1.el6.x86_64 #1 SMP Wed Oct 5 00:36:12 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
# cat /etc/centos-release
CentOS release 6.8 (Final)
# yum list installed | grep openvas
openvas.noarch1.0-17.el6.art
@atomic
openvas-cli.x86_641.4.3-9.el6.art
@atomic
openvas-libraries.x86_64  8.0.7-24.el6.art
@atomic
openvas-manager.x86_646.0.8-35.el6.art
@atomic
openvas-scanner.x86_645.0.5-23.el6.art
@atomic
openvas-smb.x86_641.0.1-1.el6.art
@atomic
# openvas-check-setup --v8 --server
openvas-check-setup 2.3.0
  Test completeness and readiness of OpenVAS-8
  (add '--v6' or '--v7' or '--9'
   if you want to check for another OpenVAS version)

  Please report us any non-detected problems and
  help us to improve this check routine:
  http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

  Send us the log-file (/tmp/openvas-check-setup.log) to help analyze the
problem.

Step 1: Checking OpenVAS Scanner ...
OK: OpenVAS Scanner is present in version 5.0.5.
OK: OpenVAS Scanner CA Certificate is present as
/var/lib/openvas/CA/cacert.pem.
OK: NVT collection in /var/lib/openvas/plugins contains 50010 NVTs.
WARNING: Signature checking of NVTs is not enabled in OpenVAS
Scanner.
SUGGEST: Enable signature checking (see
http://www.openvas.org/trusted-nvts.html).
OK: The NVT cache in /var/cache/openvas contains 50021 files for
50010 NVTs.
OK: redis-server is present in version v=3.2.0.
OK: scanner (kb_location setting) is configured properly using the
redis-server socket: /tmp/redis.sock
OK: redis-server is running and listening on socket:
/tmp/redis.sock.
OK: redis-server configuration is OK and redis-server is running.
Step 2: Checking OpenVAS Manager ...
OK: OpenVAS Manager is present in version 6.0.8.
OK: OpenVAS Manager client certificate is present as
/var/lib/openvas/CA/clientcert.pem.
OK: OpenVAS Manager database found in /var/lib/openvas/mgr/tasks.db.
OK: Access rights for the OpenVAS Manager database are correct.
OK: At least one user exists.
OK: sqlite3 found, extended checks of the OpenVAS Manager
installation enabled.
OK: OpenVAS Manager database is at revision 146.
OK: OpenVAS Manager expects database at revision 146.
OK: Database schema is up to date.
OK: OpenVAS Manager database contains information about 49747 NVTs.
OK: OpenVAS SCAP database found in
/var/lib/openvas/scap-data/scap.db.
OK: OpenVAS CERT database found in
/var/lib/openvas/cert-data/cert.db.
OK: xsltproc found.
Step 3: Checking user configuration ...
WARNING: Your password policy is empty.
SUGGEST: Edit the /etc/openvas/pwpolicy.conf file to set a password
policy.
Step 4: Checking Greenbone Security Assistant (GSA) ...
OK: Greenbone Security Assistant is present in version 6.0.10.
Step 5: Checking OpenVAS CLI ...
SKIP: