from:"Corti Matteo \(ID BD\)"

Re: [Openvas-discuss] Creating new alerts hangs

2018-06-13 Thread Corti Matteo (ID BD)

Hi

If anyone is interested: it seems related to Safari on macOS. With Chrome it 
works …

Matteo

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch

> On 15 May 2018, at 09:08, Corti Matteo (ID BD)  wrote:
> 
> Hi
> 
> I just noticed that I can create a task when adding the IPs with a file.
> 
> But I have the same problem (“Creating…” forever) when creating an email alert
> 
> Matteo
> 
>> On 9 May 2018, at 12:14 , Corti Matteo (ID BD) > <mailto:co...@ethz.ch>> wrote:
>> 
>> Hi
>> 
>> When trying to create new alerts Greenbone hangs forever:
>> 
>> 
>> 
>> Setup seems OK:
>> 
>> # ./openvas-check-setup --v9
>> openvas-check-setup 2.3.7
>>   Test completeness and readiness of OpenVAS-9
>> 
>>   Please report us any non-detected problems and
>>   help us to improve this check routine:
>>   http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss 
>> <http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss>
>> 
>>   Send us the log-file (/tmp/openvas-check-setup.log) to help analyze the 
>> problem.
>> 
>>   Use the parameter --server to skip checks for client tools
>>   like GSD and OpenVAS-CLI.
>> 
>> Step 1: Checking OpenVAS Scanner ... 
>> OK: OpenVAS Scanner is present in version 5.1.1.
>> OK: redis-server is present in version v=3.0.7.
>> 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.
>> OK: NVT collection in /var/lib/openvas/plugins contains 44792 NVTs.
>> OK: Signature checking of NVTs is enabled in OpenVAS Scanner.
>> OK: The NVT cache in /var/cache/openvas contains 44888 files for 
>> 44792 NVTs.
>> Step 2: Checking OpenVAS Manager ... 
>> OK: OpenVAS Manager is present in version 7.0.2.
>> OK: OpenVAS Manager database found in /var/lib/openvas/mgr/tasks.db.
>> OK: Access rights for the OpenVAS Manager database are correct.
>> OK: sqlite3 found, extended checks of the OpenVAS Manager 
>> installation enabled.
>> OK: OpenVAS Manager database is at revision 184.
>> OK: OpenVAS Manager expects database at revision 184.
>> OK: Database schema is up to date.
>> OK: OpenVAS Manager database contains information about 44791 NVTs.
>> OK: At least one user exists.
>> 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 ... 
>> OK: The password policy file at /etc/openvas/pwpolicy.conf contains 
>> entries.
>> Step 4: Checking Greenbone Security Assistant (GSA) ... 
>> OK: Greenbone Security Assistant is present in version 7.0.2.
>> OK: Your OpenVAS certificate infrastructure passed validation.
>> Step 5: Checking OpenVAS CLI ... 
>> OK: OpenVAS CLI version 1.4.5.
>> Step 6: Checking Greenbone Security Desktop (GSD) ... 
>> SKIP: Skipping check for Greenbone Security Desktop.
>> Step 7: Checking if OpenVAS services are up and running ... 
>> OK: netstat found, extended checks of the OpenVAS services enabled.
>> OK: OpenVAS Scanner is running and listening on a Unix domain socket.
>> OK: OpenVAS Manager is running and listening on a Unix domain socket.
>> OK: Greenbone Security Assistant is listening on port 80, which is 
>> the default port.
>> Step 8: Checking nmap installation ...
>> WARNING: Your version of nmap is not fully supported: 6.47
>> SUGGEST: You should install nmap 5.51 if you plan to use the nmap 
>> NSE NVTs.
>> Step 10: Checking presence of optional tools ...
>> OK: pdflatex found.
>> OK: PDF generation successful. The PDF report format is likely to 
>> work.
>> OK: ssh-keygen found, LSC credential generation for GNU/Linux 
>> targets is likely to work.
>> OK: rpm found, LSC credential package generation for RPM based 
>> targets is likely to work.
>> OK: alien found, LSC credential package generation for DEB based 
>> targets is likely to work.
>> OK: nsis found, LSC credential package

[Openvas-discuss] Forcing a deep scan

2018-05-15 Thread Corti Matteo (ID BD)

Hi

I have a target configured with a "Full and fast ultimate” config. We now 
installed a lot of new stuff on the targeted machines but I am not able to tell 
OpenVAS to *temporarily* ignore the last scans and perform a “very deep” scan.

Is there a quick way or creating a new Task is the only way?

Matteo


-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Creating new alerts hangs

2018-05-15 Thread Corti Matteo (ID BD)

Hi

I just noticed that I can create a task when adding the IPs with a file.

But I have the same problem (“Creating…” forever) when creating an email alert

Matteo

> On 9 May 2018, at 12:14 , Corti Matteo (ID BD) <co...@ethz.ch> wrote:
> 
> Hi
> 
> When trying to create new alerts Greenbone hangs forever:
> 
> 
> 
> Setup seems OK:
> 
> # ./openvas-check-setup --v9
> openvas-check-setup 2.3.7
>   Test completeness and readiness of OpenVAS-9
> 
>   Please report us any non-detected problems and
>   help us to improve this check routine:
>   http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss 
> <http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss>
> 
>   Send us the log-file (/tmp/openvas-check-setup.log) to help analyze the 
> problem.
> 
>   Use the parameter --server to skip checks for client tools
>   like GSD and OpenVAS-CLI.
> 
> Step 1: Checking OpenVAS Scanner ... 
> OK: OpenVAS Scanner is present in version 5.1.1.
> OK: redis-server is present in version v=3.0.7.
> 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.
> OK: NVT collection in /var/lib/openvas/plugins contains 44792 NVTs.
> OK: Signature checking of NVTs is enabled in OpenVAS Scanner.
> OK: The NVT cache in /var/cache/openvas contains 44888 files for 
> 44792 NVTs.
> Step 2: Checking OpenVAS Manager ... 
> OK: OpenVAS Manager is present in version 7.0.2.
> OK: OpenVAS Manager database found in /var/lib/openvas/mgr/tasks.db.
> OK: Access rights for the OpenVAS Manager database are correct.
> OK: sqlite3 found, extended checks of the OpenVAS Manager 
> installation enabled.
> OK: OpenVAS Manager database is at revision 184.
> OK: OpenVAS Manager expects database at revision 184.
> OK: Database schema is up to date.
> OK: OpenVAS Manager database contains information about 44791 NVTs.
> OK: At least one user exists.
> 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 ... 
> OK: The password policy file at /etc/openvas/pwpolicy.conf contains 
> entries.
> Step 4: Checking Greenbone Security Assistant (GSA) ... 
> OK: Greenbone Security Assistant is present in version 7.0.2.
> OK: Your OpenVAS certificate infrastructure passed validation.
> Step 5: Checking OpenVAS CLI ... 
> OK: OpenVAS CLI version 1.4.5.
> Step 6: Checking Greenbone Security Desktop (GSD) ... 
> SKIP: Skipping check for Greenbone Security Desktop.
> Step 7: Checking if OpenVAS services are up and running ... 
> OK: netstat found, extended checks of the OpenVAS services enabled.
> OK: OpenVAS Scanner is running and listening on a Unix domain socket.
> OK: OpenVAS Manager is running and listening on a Unix domain socket.
> OK: Greenbone Security Assistant is listening on port 80, which is 
> the default port.
> Step 8: Checking nmap installation ...
> WARNING: Your version of nmap is not fully supported: 6.47
> SUGGEST: You should install nmap 5.51 if you plan to use the nmap NSE 
> NVTs.
> Step 10: Checking presence of optional tools ...
> OK: pdflatex found.
> OK: PDF generation successful. The PDF report format is likely to 
> work.
> OK: ssh-keygen found, LSC credential generation for GNU/Linux targets 
> is likely to work.
> OK: rpm found, LSC credential package generation for RPM based 
> targets is likely to work.
> OK: alien found, LSC credential package generation for DEB based 
> targets is likely to work.
> OK: nsis found, LSC credential package generation for Microsoft 
> Windows targets is likely to work.
> OK: SELinux is disabled.
> 
> It seems like your OpenVAS-9 installation is OK.
> 
> If you think it is not OK, please report your observation
> and help us to improve this check routine:
> http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss 
> <http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss>
> Please attach the log-file (/tmp/openvas-check-setup.log) to help us analyze 
> the problem.
> 
> 
> The logs do not show anything
> 
> Any hint on what could be the problem?
> 
> Many thanks
> 
> Matteo
> 
> -- 
> ETH Zurich, Dr. Matteo

[Openvas-discuss] Process XY (OID: XY) seems to have died too early

2017-11-20 Thread Corti Matteo (ID BD)

Hi

I am using Openvas 9 and I often (every couple of days) see the following error 
in the log

Process 3457 (OID: 1.3.6.1.4.1.25623.1.0.100871) seems to have died too 
early

After the sudden stop, I am not able to start any scan.

I have to:

kill the scanner
kill the manager
stop redis
remove the redis db
start the scanner
rebuild the db
start the manager

After this I can restart the interrupted scans.

Any idea on what the problem could be?

Matteo

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Problem starting gsa

2017-01-31 Thread Corti Matteo (ID BD)

Dear Harald

thanks, I am indeed using Fedora.

Matteo

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch

> On 31 Jan 2017, at 13:43, Reindl Harald <h.rei...@thelounge.net> wrote:
> 
> next time mention your operating system and package versions
> https://bugzilla.redhat.com/show_bug.cgi?id=1416034
> 
> a new build is in testing and and then 0.9.52 should work too
> 
> Am 31.01.2017 um 11:56 schrieb Corti Matteo (ID BD):
>> give no output with the following entries in the log file
>> 
>>gsad main:  DEBUG:2017-01-31 10h49.22 utc:24066: main: gettext
>>translation extensions are enabled (using locale "en_US.UTF-8").
>>gsad main:  DEBUG:2017-01-31 10h49.22 utc:24066: Forking...
>>gsad main:  DEBUG:2017-01-31 10h49.22 utc:24067: Forking for redirect...
>>gsad main:CRITICAL:2017-01-31 10h49.22 utc:24067: main:
>>start_https_daemon failed!
> ___
> Openvas-discuss mailing list
> Openvas-discuss@wald.intevation.org
> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Problem starting gsa

2017-01-31 Thread Corti Matteo (ID BD)

Dear Christian

Thanks for the hint but

/usr/sbin/gsad --no-redirect  --port=9392 --mport=9390 
--mlisten=127.0.0.1 
--gnutls-priorities=SECURE128:-AES-128-CBC:-CAMELLIA-128-CBC:-VERS-SSL3.0:-VERS-TLS1.0
 -f -vvv

gives no improvement

gsad main:  DEBUG:2017-01-31 11h24.01 utc:32463: main: gettext translation 
extensions are enabled (using locale "en_US.UTF-8").
gsad main:CRITICAL:2017-01-31 11h24.01 utc:32463: main: start_https_daemon 
failed!

Now with --http-only it starts but listens only on IPv6

$ netstat -anp | grep 372
tcp6   0  0 :::9392 :::*LISTEN  
372/gsad

Matteo


-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch

> On 31 Jan 2017, at 12:03, Christian Fischer <christian.fisc...@greenbone.net> 
> wrote:
> 
> Hi,
> 
> On 31.01.2017 11:56, Corti Matteo (ID BD) wrote:
>> Why is gsad trying to use port 80?
> 
> i think because of the following:
> 
>> gsad main:  DEBUG:2017-01-31 10h49.22 utc:24067: Forking for redirect...
>> gsad main:WARNING:2017-01-31 10h49.22 utc:24068: main:
> start_http_daemon redirect failed !
> 
> Have a look at the --no-redirect parameter of gsad which disables this
> behavior:
> 
> --no-redirect  Don't redirect HTTP to HTTPS.
> 
> Regards,
> 
> -- 
> 
> Christian Fischer | PGP Key: 0x54F3CE5B76C597AD
> Greenbone Networks GmbH | http://greenbone.net
> Neumarkt 12, 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



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

[Openvas-discuss] Problem starting gsa

2017-01-31 Thread Corti Matteo (ID BD)

Hi

Since a couple of days I am no more able to start gsa.

For example

$ /usr/sbin/gsad --port=9392 --mport=9390 --mlisten=127.0.0.1 
--gnutls-priorities=SECURE128:-AES-128-CBC:-CAMELLIA-128-CBC:-VERS-SSL3.0:-VERS-TLS1.0
 -vvv

give no output with the following entries in the log file

gsad main:  DEBUG:2017-01-31 10h49.22 utc:24066: main: gettext translation 
extensions are enabled (using locale "en_US.UTF-8").
gsad main:  DEBUG:2017-01-31 10h49.22 utc:24066: Forking...
gsad main:  DEBUG:2017-01-31 10h49.22 utc:24067: Forking for redirect...
gsad main:CRITICAL:2017-01-31 10h49.22 utc:24067: main: start_https_daemon 
failed!
gsad main:WARNING:2017-01-31 10h49.22 utc:24068: MHD: Failed to listen for 
connections: Address already in use
gsad main:WARNING:2017-01-31 10h49.22 utc:24068: main: start_http_daemon 
redirect failed !

Manager is running and listening to 9390

$ telnet 127.0.0.1 9390
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]

telnet> close
Connection closed.
$ 

And nothing is already listening on port 9392

$ netstat -anp | grep 9392
$ 

Executing it with strace I see that it tries to use port 80 with IPv6

[pid 24762] bind(4, {sa_family=AF_INET6, sin6_port=htons(80), 
inet_pton(AF_INET6, "::", _addr), sin6_flowinfo=htonl(0), 
sin6_scope_id=0}, 28 

Port 80 *is* already used.

Why is gsad trying to use port 80?

Thanks in advance

Matteo

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Scans go letargic after a while

2016-10-17 Thread Corti Matteo (ID BD)

Hi

> On 17.10.2016 13:53, Corti Matteo (ID BD) wrote:
>> I have to stop redis, delete /var/lib/redis/dump.rdb and restart redis.
> 
> this sounds like the known redis issues which where discussed here at
> the ML in the past. See the following ML post for a possible workaround:
> 
> https://lists.wald.intevation.org/pipermail/openvas-discuss/2016-September/010061.html


Thanks

I deleted the “save” option in the configuration and performed the integrity 
check without errors.

It was running (without saving to dump.rdb) for 4-5 hours and then stopped 
again …

Any other idea?

Matteo

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

[Openvas-discuss] Scans go letargic after a while

2016-10-17 Thread Corti Matteo (ID BD)

Hi

When I start a scan it goes well for a short while (3%-4%) and then OpenVAS 
stops doing anything. Load of the machine sinks to almost 0 and ps shows

root   881  0.0  0.2 186268 47860 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.80
root  1006  0.1  0.2 162792 38284 ?Ss   Oct16   2:33 openvassd: 
Waiting for incoming connections
root  1022  0.3  0.4 254832 81572 ?SL   Oct16   6:52 openvasmd
root  3088  0.0  0.2 186268 47856 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.225
root  5069  0.0  0.2 186268 47856 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.93
root  7711  0.0  0.2 186268 47260 ?SN   03:23   0:00 openvassd: 
testing 129.132.171.133
root  8478  0.0  0.2 186268 47264 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.13
root 11668  0.0  0.2 186268 47856 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.71
root 17147  0.0  0.2 186268 47856 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.150
root 20232  0.0  0.2 186268 47856 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.67
root 21689  0.0  0.2 186268 47856 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.60
root 21700  0.0  0.2 186268 47856 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.61
root 21709  0.0  0.2 186268 47852 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.63
root 21871  0.0  0.2 186268 47856 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.31
root 22868  0.0  0.2 186268 47856 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.123
root 24044  0.4  0.3 184156 50764 ?SNs  Oct16   6:59 openvassd: 
Serving 127.0.0.1
root 24114  1.7  1.3 405068 229264 ?   SOct16  28:21 openvasmd: 
OTP: Handling scan 35520572-5c1c-449c-85f9-ba7063e19f06
root 24146  0.0  0.0 273664  1260 ?Ss   Oct16   0:01 gpg-agent 
--homedir /var/lib/openvas/gnupg --use-standard-socket --daemon
root 24419  0.0  0.2 179912 47144 ?SN   Oct16   0:00 openvassd: 
testing 172.31.73.9
root 24423  0.0  0.2 179912 47224 ?SN   Oct16   0:00 openvassd: 
testing 172.31.73.13
root 24427  0.0  0.2 179912 47224 ?SN   Oct16   0:00 openvassd: 
testing 172.31.73.17
root 24429  0.0  0.2 179912 47224 ?SN   Oct16   0:00 openvassd: 
testing 172.31.73.19
root 27318  0.0  0.2 186268 47856 ?SN   00:45   0:00 openvassd: 
testing 129.132.202.232
root 27448  0.0  0.2 186268 47856 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.97
root 27468  0.0  0.2 186268 47856 ?SN   Oct16   0:00 openvassd: 
testing 129.132.202.218

It seems that there are several machines in the queue but nothing happens.

If I restart OpenVAS the problem persist. I have to stop redis, delete 
/var/lib/redis/dump.rdb and restart redis.

Any hint on how to solve the problem?

Matteo

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

[Openvas-discuss] False positives by pfile Multiple Cross Site Scripting and SQL Injection Vulnerabilities

2016-09-20 Thread Corti Matteo (ID BD)

Hi

I get a warning for "pfile Multiple Cross Site Scripting and SQL Injection 
Vulnerabilities” (http://plugins.openvas.org/nasl.php?oid=103435)

The tested server hosts MailCleaner (http://www.mailcleaner.net), an mail 
filter which does *not* use pfile

The plugin tries to access 
https://mailcleaner.ethz.ch/users/kommentar.php?filecat=;>alert(/openvas-xss-test/)=0
 and checks for the following pattern in the output
"alert\(/openvas-xss-test/\)"

Check in the script
  if( http_vuln_check( port:port, url:url, 
pattern:"alert\(/openvas-xss-test/\)", check_header:TRUE ) ) {


Our application outputs a pretty long error containing

[…]
  string(44) "Invalid controller specified (kommentar.php)”
[…]

and then

[…]
  ["_requestUri":protected]=>
  string(82) 
"/users/kommentar.php?filecat=">alert(/openvas-xss-test/)=0”
[…]

I think that the plugin should be more specific in the check as I might imagine 
that also other applications would put the “offending” request in an error 
output.

Matteo

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] SMB Brute Force Logins With Default Credentials (OID: 1.3.6.1.4.1.25623.1.0.804449)

2016-08-09 Thread Corti Matteo (ID BD)

Thanks, indeed!

smbclient //*/IPC$ -U admin%admin
Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
smb: \> 


Matteo

> On 08 Aug 2016, at 23:19, Eero Volotinen <eero.voloti...@iki.fi> wrote:
> 
> try this
> 
> smbclient //ipaddress/IPC$ -U admin%admin
> 
> 
> 
> 2016-08-08 23:11 GMT+03:00 Eero Volotinen <eero.voloti...@iki.fi 
> <mailto:eero.voloti...@iki.fi>>:
> This plugin is used to detect issue:
> 
> http://plugins.openvas.org/nasl.php?oid=804449 
> <http://plugins.openvas.org/nasl.php?oid=804449>
> 
> Looks like it's connecting to IPC$ share.
> 
> --
> Eero
> 
> 2016-08-08 22:01 GMT+03:00 Corti Matteo (ID BD) <co...@ethz.ch 
> <mailto:co...@ethz.ch>>:
> Dear Eero
> 
> I appreciate the help but the question is not how to secure/firewall the 
> server. The question is why OpenVAS is telling that is possible to connect as 
> admin:admin and I cannot verify the problem.
> 
> What is tested? How can I reproduce the problem? I checked the configuration 
> and the admin password is *not* admin.
> 
> Could it be that the plugin is reporting a false positive?
> 
> Matteo
> 
>> On 08 Aug 2016, at 20:49 , Eero Volotinen <eero.voloti...@iki.fi 
>> <mailto:eero.voloti...@iki.fi>> wrote:
>> 
>> Well. exposing samba protocol to internet without ipsec is not wise thing to 
>> do. It might be also problem with NVT.
>> 
>> Eero
>> 
>> 2016-08-08 21:45 GMT+03:00 Corti Matteo (ID BD) <co...@ethz.ch 
>> <mailto:co...@ethz.ch>>:
>> Hi
>> 
>>> On 08 Aug 2016, at 16:42 , Eero Volotinen <eero.voloti...@iki.fi 
>>> <mailto:eero.voloti...@iki.fi>> wrote:
>>> 
>>> You are sensoring the input, so it's bit hard to guess the parameters.
>> 
>> Just the IP address. If the server is really vulnerable it would be unwise 
>> to tell it to the whole world
>>> 
>>> try something like smbclient //ip.address/sharename -U admin%admin or
>>> smbclient //ip.address/c$ -U admin%admin
>> 
>> $  smbclient //*/climbing -U admin%admin
>> Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
>> tree connect failed: NT_STATUS_ACCESS_DENIED
>> $ smbclient //*/c$ -U admin%admin
>> Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
>> tree connect failed: NT_STATUS_BAD_NETWORK_NAME
>> 
>> It is not a problem with the smbclient syntax. I can also try to mount the 
>> share with an OS X or Windows machine.
>> 
>> Same result.
>> 
>> Matteo
>> 
>>> 
>>> 2016-08-08 17:22 GMT+03:00 Corti Matteo (ID BD) <co...@ethz.ch 
>>> <mailto:co...@ethz.ch>>:
>>> Hi
>>> 
>>> it is strange but OK according to the man page
>>> 
>>>   smbclient {servicename} [password] [-b ] [-d debuglevel] 
>>> [-e] [-D Directory] [-U username] [-W workgroup] [-M ] [-m 
>>> maxprotocol] [-A authfile] [-N] [-C] [-g]
>>> [-l log-basename] [-I destinationIP] [-E] [-c ] [-i 
>>> scope] [-O ] [-p port] [-R ] [-s >> config file>] [-t ]
>>>     [-T<c|x>IXFqgbNan] [-k]
>>> 
>>> In any case also supplying the password manually gives the same result
>>> 
>>> $ smbclient //*/climbing -U admin
>>> Enter admin's password: 
>>> Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
>>> tree connect failed: NT_STATUS_ACCESS_DENIED
>>> 
>>> Matteo
>>> 
>>> 
>>>> On 08 Aug 2016, at 16:18, Eero Volotinen <eero.voloti...@iki.fi 
>>>> <mailto:eero.voloti...@iki.fi>> wrote:
>>>> 
>>>> Your smbclient syntax looks incorrect. Please check out the manpage..
>>>> 
>>>> Eero
>>>> 
>>>> 
>>>> 8.8.2016 5.14 ip. "Corti Matteo (ID BD)" <co...@ethz.ch 
>>>> <mailto:co...@ethz.ch>> kirjoitti:
>>>> Hi
>>>> 
>>>> a recent scan shows a lot of hosts with
>>>> 
>>>> SMB Brute Force Logins With Default Credentials (OID: 
>>>> 1.3.6.1.4.1.25623.1.0.804449) 
>>>> <https://matteo.ethz.ch:9392/omp?cmd=get_info_type=nvt_id=1.3.6.1.4.1.25623.1.0.804449=8625b2bf-59ca-4554-917f-e9d27a4e09c4>
>>>> 
>>>> with the following result
>>>> 
>>>> Vulnerability Detection Result
>>>> It was possible to login with the following credentials via the SMB 
>>>> protocol. :<Pass↵
>>>> word>
>>>> 
>>>> admin:admin
>

Re: [Openvas-discuss] SMB Brute Force Logins With Default Credentials (OID: 1.3.6.1.4.1.25623.1.0.804449)

2016-08-08 Thread Corti Matteo (ID BD)

Dear Eero

I appreciate the help but the question is not how to secure/firewall the 
server. The question is why OpenVAS is telling that is possible to connect as 
admin:admin and I cannot verify the problem.

What is tested? How can I reproduce the problem? I checked the configuration 
and the admin password is *not* admin.

Could it be that the plugin is reporting a false positive?

Matteo

> On 08 Aug 2016, at 20:49 , Eero Volotinen <eero.voloti...@iki.fi> wrote:
> 
> Well. exposing samba protocol to internet without ipsec is not wise thing to 
> do. It might be also problem with NVT.
> 
> Eero
> 
> 2016-08-08 21:45 GMT+03:00 Corti Matteo (ID BD) <co...@ethz.ch 
> <mailto:co...@ethz.ch>>:
> Hi
> 
>> On 08 Aug 2016, at 16:42 , Eero Volotinen <eero.voloti...@iki.fi 
>> <mailto:eero.voloti...@iki.fi>> wrote:
>> 
>> You are sensoring the input, so it's bit hard to guess the parameters.
> 
> Just the IP address. If the server is really vulnerable it would be unwise to 
> tell it to the whole world
>> 
>> try something like smbclient //ip.address/sharename -U admin%admin or
>> smbclient //ip.address/c$ -U admin%admin
> 
> $  smbclient //*/climbing -U admin%admin
> Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
> tree connect failed: NT_STATUS_ACCESS_DENIED
> $ smbclient //*/c$ -U admin%admin
> Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
> tree connect failed: NT_STATUS_BAD_NETWORK_NAME
> 
> It is not a problem with the smbclient syntax. I can also try to mount the 
> share with an OS X or Windows machine.
> 
> Same result.
> 
> Matteo
> 
>> 
>> 2016-08-08 17:22 GMT+03:00 Corti Matteo (ID BD) <co...@ethz.ch 
>> <mailto:co...@ethz.ch>>:
>> Hi
>> 
>> it is strange but OK according to the man page
>> 
>>   smbclient {servicename} [password] [-b ] [-d debuglevel] [-e] 
>> [-D Directory] [-U username] [-W workgroup] [-M ] [-m 
>> maxprotocol] [-A authfile] [-N] [-C] [-g]
>> [-l log-basename] [-I destinationIP] [-E] [-c ] [-i 
>> scope] [-O ] [-p port] [-R ] [-s > config file>] [-t ]
>> [-T<c|x>IXFqgbNan] [-k]
>> 
>> In any case also supplying the password manually gives the same result
>> 
>> $ smbclient //*/climbing -U admin
>> Enter admin's password: 
>> Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
>> tree connect failed: NT_STATUS_ACCESS_DENIED
>> 
>> Matteo
>> 
>> 
>>> On 08 Aug 2016, at 16:18, Eero Volotinen <eero.voloti...@iki.fi 
>>> <mailto:eero.voloti...@iki.fi>> wrote:
>>> 
>>> Your smbclient syntax looks incorrect. Please check out the manpage..
>>> 
>>> Eero
>>> 
>>> 
>>> 8.8.2016 5.14 ip. "Corti Matteo (ID BD)" <co...@ethz.ch 
>>> <mailto:co...@ethz.ch>> kirjoitti:
>>> Hi
>>> 
>>> a recent scan shows a lot of hosts with
>>> 
>>>  SMB Brute Force Logins With Default Credentials (OID: 
>>> 1.3.6.1.4.1.25623.1.0.804449) 
>>> <https://matteo.ethz.ch:9392/omp?cmd=get_info_type=nvt_id=1.3.6.1.4.1.25623.1.0.804449=8625b2bf-59ca-4554-917f-e9d27a4e09c4>
>>> 
>>> with the following result
>>> 
>>> Vulnerability Detection Result
>>> It was possible to login with the following credentials via the SMB 
>>> protocol. :<Pass↵
>>> word>
>>> 
>>> admin:admin
>>> 
>>> I am trying to check with smbclient and I don’t succeed
>>> 
>>> $ smbclient //***.***.***.***/climbing admin -U admin
>>> Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
>>> tree connect failed: NT_STATUS_ACCESS_DENIED
>>> 
>>> What am I missing?
>>> 
>>> Regards
>>> 
>>> Matteo
>>> 
>>> -- 
>>> ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
>>> STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
>>> Tel +41 44 63 27944, http://www.id.ethz.ch <http://www.id.ethz.ch/>
>>> 
>>> ___
>>> Openvas-discuss mailing list
>>> Openvas-discuss@wald.intevation.org 
>>> <mailto:Openvas-discuss@wald.intevation.org>
>>> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss 
>>> <https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss>
>> 
>> -- 
>> ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
>> STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
>> Tel +41 44 63 27944, http://www.id.ethz.ch <http://www.id.ethz.ch/>
>> 
> 
> 
> -- 
> ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
> STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
> Tel +41 44 63 27944, http://www.id.ethz.ch <http://www.id.ethz.ch/>
> 

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] SMB Brute Force Logins With Default Credentials (OID: 1.3.6.1.4.1.25623.1.0.804449)

2016-08-08 Thread Corti Matteo (ID BD)

Hi

> On 08 Aug 2016, at 20:55 , Reindl Harald  wrote:
>> Well. exposing samba protocol to internet without ipsec is not wise
>> thing to do. It might be also problem with NVT
> 
> it's not unwise, it's just a *absolute* no-go having samba/nfs/netatalk on a 
> wan-interface without a secured tunnel and "If the server is really 
> vulnerable it would be unwise to tell it to the whole world" is naive because 
> the whole world knows except the good guys

I never said it was exposed. And it is not. SMB is blocked by our border 
routers. But I don’t think that the IP address of the machine is relevant. If 
you really think (?) that it is essential to the question I can also post it. 
But I really don’t see the point of the problem.

Matteo


> just try it out - connect a samba machine on a IP never hosted a server with 
> a guest account to the internet and you can't smoke a cigarette before the 
> first malware arrives
> 
> top honeypot ports this month
> column 3 is the connect count
> 
> 1 23  454251  telnet
> 2 22  84318   ssh
> 3 590035586   vnc
> 4 445 35107   smb
> 
> ___
> Openvas-discuss mailing list
> Openvas-discuss@wald.intevation.org
> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] SMB Brute Force Logins With Default Credentials (OID: 1.3.6.1.4.1.25623.1.0.804449)

2016-08-08 Thread Corti Matteo (ID BD)

Hi

> On 08 Aug 2016, at 16:42 , Eero Volotinen <eero.voloti...@iki.fi> wrote:
> 
> You are sensoring the input, so it's bit hard to guess the parameters.

Just the IP address. If the server is really vulnerable it would be unwise to 
tell it to the whole world
> 
> try something like smbclient //ip.address/sharename -U admin%admin or
> smbclient //ip.address/c$ -U admin%admin

$  smbclient //*/climbing -U admin%admin
Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
tree connect failed: NT_STATUS_ACCESS_DENIED
$ smbclient //*/c$ -U admin%admin
Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
tree connect failed: NT_STATUS_BAD_NETWORK_NAME

It is not a problem with the smbclient syntax. I can also try to mount the 
share with an OS X or Windows machine.

Same result.

Matteo

> 
> 2016-08-08 17:22 GMT+03:00 Corti Matteo (ID BD) <co...@ethz.ch 
> <mailto:co...@ethz.ch>>:
> Hi
> 
> it is strange but OK according to the man page
> 
>   smbclient {servicename} [password] [-b ] [-d debuglevel] [-e] 
> [-D Directory] [-U username] [-W workgroup] [-M ] [-m 
> maxprotocol] [-A authfile] [-N] [-C] [-g]
> [-l log-basename] [-I destinationIP] [-E] [-c ] [-i 
> scope] [-O ] [-p port] [-R ] [-s  config file>] [-t ]
> [-T<c|x>IXFqgbNan] [-k]
> 
> In any case also supplying the password manually gives the same result
> 
> $ smbclient //*/climbing -U admin
> Enter admin's password: 
> Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
> tree connect failed: NT_STATUS_ACCESS_DENIED
> 
> Matteo
> 
> 
>> On 08 Aug 2016, at 16:18, Eero Volotinen <eero.voloti...@iki.fi 
>> <mailto:eero.voloti...@iki.fi>> wrote:
>> 
>> Your smbclient syntax looks incorrect. Please check out the manpage..
>> 
>> Eero
>> 
>> 
>> 8.8.2016 5.14 ip. "Corti Matteo (ID BD)" <co...@ethz.ch 
>> <mailto:co...@ethz.ch>> kirjoitti:
>> Hi
>> 
>> a recent scan shows a lot of hosts with
>> 
>>   SMB Brute Force Logins With Default Credentials (OID: 
>> 1.3.6.1.4.1.25623.1.0.804449) 
>> <https://matteo.ethz.ch:9392/omp?cmd=get_info_type=nvt_id=1.3.6.1.4.1.25623.1.0.804449=8625b2bf-59ca-4554-917f-e9d27a4e09c4>
>> 
>> with the following result
>> 
>> Vulnerability Detection Result
>> It was possible to login with the following credentials via the SMB 
>> protocol. :<Pass↵
>> word>
>> 
>> admin:admin
>> 
>> I am trying to check with smbclient and I don’t succeed
>> 
>> $ smbclient //***.***.***.***/climbing admin -U admin
>> Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
>> tree connect failed: NT_STATUS_ACCESS_DENIED
>> 
>> What am I missing?
>> 
>> Regards
>> 
>> Matteo
>> 
>> -- 
>> ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
>> STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
>> Tel +41 44 63 27944, http://www.id.ethz.ch <http://www.id.ethz.ch/>
>> 
>> ___
>> Openvas-discuss mailing list
>> Openvas-discuss@wald.intevation.org 
>> <mailto:Openvas-discuss@wald.intevation.org>
>> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss 
>> <https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss>
> 
> -- 
> ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
> STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
> Tel +41 44 63 27944, http://www.id.ethz.ch <http://www.id.ethz.ch/>
> 

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

[Openvas-discuss] SMB Brute Force Logins With Default Credentials (OID: 1.3.6.1.4.1.25623.1.0.804449)

2016-08-08 Thread Corti Matteo (ID BD)

Hi

a recent scan shows a lot of hosts with

 SMB Brute Force Logins With Default Credentials (OID: 
1.3.6.1.4.1.25623.1.0.804449) 


with the following result

Vulnerability Detection Result
It was possible to login with the following credentials via the SMB protocol. 
:

admin:admin

I am trying to check with smbclient and I don’t succeed

$ smbclient //***.***.***.***/climbing admin -U admin
Domain=[D] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
tree connect failed: NT_STATUS_ACCESS_DENIED

What am I missing?

Regards

Matteo

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

[Openvas-discuss] Which ports

2016-06-24 Thread Corti Matteo (ID BD)

Hi

I would like to scan for default Tomcat users and passwords on machines running 
Tomcat on non-standard ports.

When I look at the plugin "Apache Tomcat Default Accounts”  
(http://plugins.openvas.org/nasl.php?oid=11204) I see
port = get_http_port(default:8080);
if ( ! port ) exit(0);
it seems that if not port is supplied then 8080 will be used. What I do not 
know is how OpenVAS will call the plugin.

How can I scan all the ports?

Thanks

Matteo

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

[Openvas-discuss] Running a script: how to specify a parameter

2016-05-25 Thread Corti Matteo (ID BD)

Hi

I would like to run a single test on the command line, for example 
(http://plugins.openvas.org/nasl.php?oid=803477)

openvas-nasl -X -t IP -i /var/lib/openvas/plugins 
/var/lib/openvas/plugins/2013/gb_miniweb_file_upload_n_dir_trav_vuln.nasl  -T -

Seems to work but I did not find out how to specify parameters (for example in 
this case the port), which is defined as 

port = get_http_port(default:8000);
if(!port){
  port = 8000;
}

Any hint?

Matteo

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] openvassd hanging

2016-05-20 Thread Corti Matteo (ID BD)

Hi

Disabled. 

$ sestatus
SELinux status: disabled

Matteo

> On 20 May 2016, at 15:35, Eero Volotinen <eero.voloti...@iki.fi> wrote:
> 
> Is the SELinux disabled or in the permissive mode?
> 
> Eero
> 
> 2016-05-20 15:31 GMT+03:00 Corti Matteo (ID BD) <co...@ethz.ch 
> <mailto:co...@ethz.ch>>:
> Hi,
> 
> I have a problem with openvassd hanging while starting:
> 
> connect(6, {sa_family=AF_LOCAL, sun_path="/tmp/redis.sock"}, 110) = 0
> fcntl64(6, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
> fcntl64(6, F_SETFL, O_RDWR) = 0
> write(6, "*3\r\n$6\r\nCONFIG\r\n$3\r\nGET\r\n$9\r\ndat"..., 40) = 40
> read(6, "*2\r\n$9\r\ndatabases\r\n$2\r\n16\r\n", 16384) = 27
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 61) = 61
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 61) = 61
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 61) = 61
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 61) = 61
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 61) = 61
> read(6, ":0\r\n", 16384)= 4
> write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 61) = 61
> read(6, ":0\r\n", 16384)= 4
> rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
> rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> nanosleep({60, 0}, 
> Seems related to redis but it seems OK:
> 
> $ redis-cli -s /tmp/redis.sock 
> redis /tmp/redis.sock> monitor
> OK
> 1463747103.045858 [0 unix:/tmp/redis.sock] "HSETNX" 
> "OpenVAS.__GlobalDBIndex" "1" "1"
> 1463747103.046033 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "2" "1"
> 1463747103.046145 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "3" "1"
> 1463747103.046244 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "4" "1"
> 1463747103.046410 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "5" "1"
> 1463747103.046528 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "6" "1"
> 1463747103.046611 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "7" "1"
> 1463747103.046703 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "8" "1"
> 1463747103.046793 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "9" "1"
> 1463747103.046887 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "10" "1"
> 1463747103.046983 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "11" "1"
> 1463747103.047084 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "12" "1"
> 1463747103.047249 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "13" "1"
> 1463747103.047344 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
> "14" "1"
> Running openvasmd --rebuild did not also bring anything ...
> 
> Thanks
> 
> Matteo
> 
> -- 
> ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
> STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
> Tel +41 44 63 27944, http://www.id.ethz.ch <http://www.id.ethz.ch/>
> 
> ___
> Openvas-discuss mailing list
> Openvas-discuss@wald.intevation.org 
> <mailto:Openvas-discuss@wald.intevation.org>
> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss 
> <https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss>
> 

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

[Openvas-discuss] openvassd hanging

2016-05-20 Thread Corti Matteo (ID BD)

Hi,

I have a problem with openvassd hanging while starting:

connect(6, {sa_family=AF_LOCAL, sun_path="/tmp/redis.sock"}, 110) = 0
fcntl64(6, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(6, F_SETFL, O_RDWR) = 0
write(6, "*3\r\n$6\r\nCONFIG\r\n$3\r\nGET\r\n$9\r\ndat"..., 40) = 40
read(6, "*2\r\n$9\r\ndatabases\r\n$2\r\n16\r\n", 16384) = 27
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 60) = 60
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 61) = 61
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 61) = 61
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 61) = 61
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 61) = 61
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 61) = 61
read(6, ":0\r\n", 16384)= 4
write(6, "*4\r\n$6\r\nHSETNX\r\n$23\r\nOpenVAS.__G"..., 61) = 61
read(6, ":0\r\n", 16384)= 4
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({60, 0}, 
Seems related to redis but it seems OK:

$ redis-cli -s /tmp/redis.sock 
redis /tmp/redis.sock> monitor
OK
1463747103.045858 [0 unix:/tmp/redis.sock] "HSETNX" 
"OpenVAS.__GlobalDBIndex" "1" "1"
1463747103.046033 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"2" "1"
1463747103.046145 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"3" "1"
1463747103.046244 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"4" "1"
1463747103.046410 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"5" "1"
1463747103.046528 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"6" "1"
1463747103.046611 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"7" "1"
1463747103.046703 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"8" "1"
1463747103.046793 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"9" "1"
1463747103.046887 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"10" "1"
1463747103.046983 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"11" "1"
1463747103.047084 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"12" "1"
1463747103.047249 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"13" "1"
1463747103.047344 [0 unix:/tmp/redis.sock] "HSETNX" "OpenVAS.__GlobalDBIndex" 
"14" "1"
Running openvasmd --rebuild did not also bring anything ...

Thanks

Matteo

-- 
ETH Zurich, Dr. Matteo Corti, Leiter ID Basisdienste
STB H 11.1, Stampfenbachstrasse 69, 8092 Zurich
Tel +41 44 63 27944, http://www.id.ethz.ch



smime.p7s
Description: S/MIME cryptographic signature
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Creating new alerts hangs

[Openvas-discuss] Forcing a deep scan

Re: [Openvas-discuss] Creating new alerts hangs

[Openvas-discuss] Process XY (OID: XY) seems to have died too early

Re: [Openvas-discuss] Problem starting gsa

Re: [Openvas-discuss] Problem starting gsa

[Openvas-discuss] Problem starting gsa

Re: [Openvas-discuss] Scans go letargic after a while

[Openvas-discuss] Scans go letargic after a while

[Openvas-discuss] False positives by pfile Multiple Cross Site Scripting and SQL Injection Vulnerabilities

Re: [Openvas-discuss] SMB Brute Force Logins With Default Credentials (OID: 1.3.6.1.4.1.25623.1.0.804449)

Re: [Openvas-discuss] SMB Brute Force Logins With Default Credentials (OID: 1.3.6.1.4.1.25623.1.0.804449)

Re: [Openvas-discuss] SMB Brute Force Logins With Default Credentials (OID: 1.3.6.1.4.1.25623.1.0.804449)

Re: [Openvas-discuss] SMB Brute Force Logins With Default Credentials (OID: 1.3.6.1.4.1.25623.1.0.804449)

[Openvas-discuss] SMB Brute Force Logins With Default Credentials (OID: 1.3.6.1.4.1.25623.1.0.804449)

[Openvas-discuss] Which ports

[Openvas-discuss] Running a script: how to specify a parameter

Re: [Openvas-discuss] openvassd hanging

[Openvas-discuss] openvassd hanging

19 matches

Site Navigation

Mail list logo

Footer information