Re: [Openvas-discuss] SSL Certificates

[Robert Fitzpatrick]

Reindl Harald wrote:

openvassd.conf *is not* the admin GUI - it's that easy
it's the scanner-daemon, the webui is gsad



I wondered as I did think that was related to scanner, but it was the 
only place found with search for certs. I only find gsad_log.conf in 
same directory, how can one update the certs for the admin GUI?


Also, I do get this in /var/log/gsad.log every time an admin page is loaded:


[root@www openvas]# tail -1 /var/log/openvas/gsad.log
gsad main:WARNING:2018-07-07 17h32.19 UTC:7619: MHD: Failed to receive data: 
The TLS connection was non-properly terminated.


--
Robert

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] SSL Certificates

[Reindl Harald]

openvassd.conf *is not* the admin GUI - it's that easy
it's the scanner-daemon, the webui is gsad

Am 07.07.2018 um 18:03 schrieb Robert Fitzpatrick:
> I tried to change the certificate for the admin GUI, key and ca file
> with Let's Encrypt cert files but site keeps using the OpenVAS cert. I
> have tried restarting both openvas-manager and openvas-scanner services
> on this CentOS 7 server. Apache already uses same certs OK. I verified
> the paths and don't find anything about certs in the docs.
> 
> Should what I'm updating work? Even tried to move the certs as I've had
> issues in the past with perms and LE certs location
> 
> [root@www ~]# tail -3 /etc/openvas/openvassd.conf
> cert_file=/etc/ssl/certs/cert.pem
> key_file=/etc/ssl/certs/privkey.pem
> ca_file=/etc/ssl/certs/chain.pem
> [root@www ~]# ls -lah /etc/ssl/certs/*pem
> -rw-r--r-- 1 root root 2.2K Jul  7 10:50 /etc/ssl/certs/cert.pem
> -rw-r--r-- 1 root root 1.7K Jul  7 10:50 /etc/ssl/certs/chain.pem
> -rw-r--r-- 1 root root 3.8K Jul  7 10:50 /etc/ssl/certs/fullchain.pem
> -rw-r--r-- 1 root root 1.7K Jul  7 10:50 /etc/ssl/certs/privkey.pem
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

[Openvas-discuss] SSL Certificates

[Robert Fitzpatrick]

Hello,

I tried to change the certificate for the admin GUI, key and ca file 
with Let's Encrypt cert files but site keeps using the OpenVAS cert. I 
have tried restarting both openvas-manager and openvas-scanner services 
on this CentOS 7 server. Apache already uses same certs OK. I verified 
the paths and don't find anything about certs in the docs.


Should what I'm updating work? Even tried to move the certs as I've had 
issues in the past with perms and LE certs location


[root@www ~]# tail -3 /etc/openvas/openvassd.conf
cert_file=/etc/ssl/certs/cert.pem
key_file=/etc/ssl/certs/privkey.pem
ca_file=/etc/ssl/certs/chain.pem
[root@www ~]# ls -lah /etc/ssl/certs/*pem
-rw-r--r-- 1 root root 2.2K Jul  7 10:50 /etc/ssl/certs/cert.pem
-rw-r--r-- 1 root root 1.7K Jul  7 10:50 /etc/ssl/certs/chain.pem
-rw-r--r-- 1 root root 3.8K Jul  7 10:50 /etc/ssl/certs/fullchain.pem
-rw-r--r-- 1 root root 1.7K Jul  7 10:50 /etc/ssl/certs/privkey.pem

--
Robert

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] When I run sudo systemctl start openvas-scanner - the system times out

[Christian Fischer]

Hi,

> What does the redis config look like?
> sudo grep -vE '^.*#|^;|^$'  /etc/redis.conf
*snip*
> save 900 1
> save 300 10
> save 60 1

which effectively means that those are not commented out or removed as
initial assumed:

> I do not have items 1 or 2 in my configuration.
> > "most likely the known issue where redis is blocking any access
by the
> scanner due to unknown reasons. This should do the trick:
>
> 1. Delete dump.rdb (somewhere in /var/run/redis or similar)
> 2. Comment out/remove all "save xy z" (e.g. save 900 1) from your
redis.conf

Regards,
On 06.07.2018 15:58, Lance M. Caven wrote:
> Lance,
> 
> What does the status say?
> sudo systemctl -l status openvas-scanner.service
> 
> openvas-scanner.service - LSB: remote network security auditor - scanner
>    Loaded: loaded (/etc/init.d/openvas-scanner; generated)
>    Active: failed (Result: timeout) since Fri 2018-07-06 08:28:05 CDT;
> 19min ago
>      Docs: man:systemd-sysv-generator(8)
>   Process: 2241 ExecStart=/etc/init.d/openvas-scanner start
> (code=killed, signal=TERM)
>     Tasks: 1 (limit: 19660)
>    CGroup: /system.slice/openvas-scanner.service
>            └─2279 /usr/sbin/openvassd
> 
> Jul 06 08:23:05 lance-desktop systemd[1]: Starting LSB: remote network
> security auditor - scanner...
> Jul 06 08:28:05 lance-desktop systemd[1]: openvas-scanner.service: Start
> operation timed out. Terminating.
> Jul 06 08:28:05 lance-desktop systemd[1]: openvas-scanner.service:
> Failed with result 'timeout'.
> Jul 06 08:28:05 lance-desktop systemd[1]: Failed to start LSB: remote
> network security auditor - scanner.
> 
> How about for the redis service as well?
> sudo systemctl -l status redis.service
> 
> ● redis-server.service - Advanced key-value store
>Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor 
> preset: enabled)
>Active: active (running) since Fri 2018-07-06 08:22:58 CDT; 34min ago
>  Docs: http://redis.io/documentation,
>man:redis-server(1)
>   Process: 1746 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf 
> (code=exited, status=0/SUCCESS)
>  Main PID: 1812 (redis-server)
> Tasks: 4 (limit: 19660)
>CGroup: /system.slice/redis-server.service
>└─1812 /usr/bin/redis-server 127.0.0.1:0 
> 
> Jul 06 08:22:58 lance-desktop systemd[1]: Starting Advanced key-value store...
> Jul 06 08:22:58 lance-desktop systemd[1]: redis-server.service: Can't open 
> PID file /var/run/redis/redis-serve
> Jul 06 08:22:58 lance-desktop systemd[1]: Started Advanced key-value store.
> 
> What does the redis config look like?
> sudo grep -vE '^.*#|^;|^$'  /etc/redis.conf
> 
> sudo grep -vE '^.*#|^;|^$' /etc/redis/redis.conf bind 127.0.0.1 ::1
> protected-mode yes port 0 tcp-backlog 511 timeout 0 tcp-keepalive 300
> daemonize yes supervised no pidfile /var/run/redis/redis-server.pid
> loglevel notice logfile /var/log/redis/redis-server.log databases 16
> always-show-logo yes save 900 1 save 300 10 save 60 1
> stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes
> dbfilename dump.rdb dir /var/lib/redis slave-serve-stale-data yes
> slave-read-only yes repl-diskless-sync no repl-diskless-sync-delay 5
> repl-disable-tcp-nodelay no slave-priority 100 lazyfree-lazy-eviction no
> lazyfree-lazy-expire no lazyfree-lazy-server-del no slave-lazy-flush no
> appendonly no appendfilename "appendonly.aof" appendfsync everysec
> no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100
> auto-aof-rewrite-min-size 64mb aof-load-truncated yes
> aof-use-rdb-preamble no lua-time-limit 5000 slowlog-log-slower-than
> 1 slowlog-max-len 128 latency-monitor-threshold 0
> notify-keyspace-events "" hash-max-ziplist-entries 512
> hash-max-ziplist-value 64 list-max-ziplist-size -2 list-compress-depth 0
> set-max-intset-entries 512 zset-max-ziplist-entries 128
> zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 activerehashing yes
> client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave
> 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 hz 10
> aof-rewrite-incremental-fsync yes unixsocket /var/run/redis/redis.sock
> unixsocketperm 755 timeout 0
> 
> 
> 
> 
> On Thu, Jul 5, 2018 at 1:34 PM Lance M. Caven  > wrote:
> 
> When I run sudo systemctl start openvas-scanner - the system times out
> Job for openvas-scanner.service failed because a timeout was exceeded.
> See "systemctl status openvas-scanner.service" and "journalctl -xe"
> for details.
> 
> The system worked on Ubuntu 18.04 on two days ago when I installed
> it.  I rebooted the computer and did run an apt update and upgrade
> on the instance.  Since that time I have not been able to get the
> Openvas-scanner to start.  
> 
> I found and attempted to follow this advice from Christian Fische -
> I do not have items 1 or 2 in my configuration.  
> 
> "most likely the known issue where redis is blocking any