well, if you are running out of time, just kill hanged nasl scripts? with kill command?
Well, not so sure, but lot of kali users are experiencing problems. -- Eero 2016-01-22 8:50 GMT+02:00 Alain du Toit <[email protected]>: > Hi Eero, > > I unfortunately cannot run the scan from scratch as I am doing it for a > customer and the time I have allocated to this project is finished. I will > have to try using CentOS in the next vulnerability assessment I do. > > Why does OpenVAS run better on CentOS than on Kali? > > > > ------------------------------ > *From:* Eero Volotinen <[email protected]> > *To:* Alain du Toit <[email protected]> > *Cc:* "[email protected]" < > [email protected]>; "[email protected]" > <[email protected]> > *Sent:* Friday, 22 January 2016, 7:40 > > *Subject:* Re: [Openvas-plugins] Stuck on certain NVT's > > Well. this kind of error is a bit hard to debug as need to way to > reproduce it on other systems. > > On my opinion, kali linux is not best platform to run OpenVAS. Can you > try same issue on centos 7 with openvas 8 from atomic corp repository? > > -- > Eero > > 2016-01-21 18:47 GMT+02:00 Alain du Toit <[email protected]>: > > Hi, > > Yes, it isn't the same process, it's just one of many openvassd processes > that the system seems to be stuck on or rather it is one of many "sleeping" > processes related to openvassd. I started the scan over 20 hours ago and > it is still running and stuck at 99%. > > If I run ps -aux | grep nasl I get the following: > > > > > > *root@kali:~# ps -aux | grep nasl* > > root 5670 0.0 0.5 153784 48812 ? S Jan20 0:00 > openvassd: testing 10.1.1.105 > (/var/lib/openvas/plugins/secpod_ms_office_detection_900025.nasl) > root 7680 0.0 0.5 151940 45816 ? S 11:06 0:00 > openvassd: testing 10.3.4.180 > (/var/lib/openvas/plugins/gb_sap_router_detect.nasl) > root 8685 0.0 0.5 153784 48376 ? S 16:43 0:00 > openvassd: testing 10.1.1.105 > (/var/lib/openvas/plugins/secpod_ms_office_detection_900025.nasl) > root 22118 0.0 0.6 153916 49376 ? S 14:56 0:00 > openvassd: testing 10.1.1.106 > (/var/lib/openvas/plugins/secpod_ms_office_detection_900025.nasl) > root 26403 0.0 0.5 151676 45644 ? S 18:08 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/gb_crux_products_detect.nasl) > root 26413 0.0 0.5 151808 45744 ? S 18:08 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/gb_crux_products_detect.nasl) > root 26590 0.0 0.5 151676 45664 ? S 18:09 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/gb_open_web_analytics_detect.nasl) > root 26610 0.0 0.5 151820 45764 ? S 18:09 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/gb_open_web_analytics_detect.nasl) > root 26663 0.0 0.5 151940 45916 ? S 18:09 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/secpod_apache_solr_detect.nasl) > root 26673 0.0 0.5 151940 45976 ? S 18:09 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/secpod_apache_solr_detect.nasl) > root 27938 0.0 0.5 151808 45824 ? S 18:10 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/2012/gb_b2epms_mult_sql_inj_vuln.nasl) > root 27957 0.0 0.5 151940 45928 ? S 18:10 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/2012/gb_b2epms_mult_sql_inj_vuln.nasl) > root 28188 0.1 0.5 151676 45724 ? S 18:10 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/gb_phpwiki_detect.nasl) > root 28194 0.0 0.5 151808 45816 ? S 18:10 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/gb_phpwiki_detect.nasl) > root 28749 0.3 0.5 151940 45976 ? S 18:10 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/gb_dm_filemanager_detect.nasl) > root 28771 0.0 0.5 152072 46092 ? S 18:10 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/gb_dm_filemanager_detect.nasl) > root 29055 0.0 0.5 153656 48144 ? S 18:10 0:00 > openvassd: testing 10.1.1.19 > (/var/lib/openvas/plugins/2009/secpod_expert_pdf_editorx_activex_vuln.nasl) > root 29075 0.0 0.0 12660 1624 pts/1 S+ 18:10 0:00 grep nasl > root 32161 0.0 0.5 153920 48956 ? S Jan20 0:00 > openvassd: testing 10.1.1.106 > (/var/lib/openvas/plugins/secpod_ms_office_detection_900025.nasl) > > *root@kali:~# * > > > > > > If I attach strace to any of the above process, the output I get is: > "*futex(0x7fe05ccad620, > FUTEX_WAIT_PRIVATE, 2, NULL". *However, process *7680 (the longest > running process) *has a completely different strace output when attached, > see below: > > select(25, [24], NULL, NULL, {1, 0}) = 0 (Timeout) > select(25, [24], NULL, NULL, {1, 0}) = 0 (Timeout) > select(25, [24], NULL, NULL, {1, 0}) = 0 (Timeout) > select(25, [24], NULL, NULL, {1, 0}) = 0 (Timeout) > select(25, [24], NULL, NULL, {1, 0}) = 0 (Timeout) > shutdown(24, SHUT_RDWR) = 0 > close(24) = 0 > chdir("/") = 0 > close(6) = 0 > munmap(0x7fe05e6d7000, 4096) = 0 > sendto(4, "\1\0\1\0", 4, 0, NULL, 0) = 4 > --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=26707, si_uid=0} --- > getpgrp() = 26668 > rt_sigreturn() = 4 > recvfrom(4, "\2\0\1\0", 4, 0, NULL, NULL) = 4 > exit_group(0) = ? > +++ exited with 0 +++ > > For some reason it completes the strace request. The other processes > don't complete, the terminal hangs waiting for something > > > > > > So I am confused. It seems like some processes run and finish, others are > waiting for something. I have a feeling that some processes have > dependencies in which case they are waiting for things to finish before > they continue. If I look at the process ID *7680 *strace output shown > above, it seems to be referencing another process ID in line 12 of that > output. > > I don't know why this type of scan takes so long. Why would a scan take > over 24 hours to complete, the IP count being scanned is only 20 IP's. > > Regards, > Alain > > ------------------------------ > *From:* Eero Volotinen <[email protected]> > *To:* Alain du Toit <[email protected]> > *Cc:* "[email protected]" < > [email protected]>; "[email protected]" > <[email protected]> > *Sent:* Thursday, 21 January 2016, 17:42 > > *Subject:* Re: [Openvas-plugins] Stuck on certain NVT's > > Well, I am not sure that you attached strace to correct process. This > process is waiting something? > > -- > Eero > > 2016-01-21 17:10 GMT+02:00 Alain du Toit <[email protected]>: > > Hi Eero, > > Thanks for the help but I am a bit confused, I am unsure of what I am > looking at. Please see the attached output of the strace command...Can you > make sense of it at all? > > > > ------------------------------ > *From:* Eero Volotinen <[email protected]> > *To:* Alain du Toit <[email protected]>; " > [email protected]" <[email protected]> > > *Cc:* "[email protected]" < > [email protected]> > *Sent:* Thursday, 21 January 2016, 16:06 > *Subject:* Re: [Openvas-plugins] Stuck on certain NVT's > > well. it depends on scan config.. > > try ps aux | grep nasl or similar and attach strace -f -p PID to hanged > processes to see if something really happends or not. > > Eero > > 2016-01-21 14:27 GMT+02:00 Alain du Toit <[email protected]>: > > Hi there, > > I have an OpenVas scan running, two scans in fact, using the Greenbone > Security Assistant. Please see a video I made of where the scan is getting > stuck at 99%. This is been for over 18 hours. > > Link: https://drive.google.com/open?id=0By2fpZO3ahvhTUxkZXNXRkdOc28 > > Ben from Greenbone suggested I contact your team to try workout why it's > getting stuck on these NVT's. These processes in the Linux box are > sleeping, not running. So for some reason it has gotten stuck here, some > assistance would be greatly appreciated. > > Here the name of the NVTs that are stuck: > > - secpod_ms_office_detection_900025 (x2) > - gb_sap_router_detect > > Thank you... > Regards, > Alain > > > > _______________________________________________ > Openvas-plugins mailing list > [email protected] > https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-plugins > > > > > > > > > > >
_______________________________________________ Openvas-discuss mailing list [email protected] https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
