1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
socket: 0.670
vnc: 0.624
network: 0.593
device: 0.527
ppc: 0.356
performance: 0.344
register: 0.342
semantic: 0.300
mistranslation: 0.280
files: 0.278
kernel: 0.277
PID: 0.263
hypervisor: 0.246
permissions: 0.217
arm: 0.216
risc-v: 0.202
architecture: 0.191
x86: 0.182
assembly: 0.166
virtual: 0.166
KVM: 0.165
i386: 0.162
boot: 0.153
TCG: 0.143
user-level: 0.138
VMM: 0.129
debug: 0.117
graphic: 0.113
peripherals: 0.102
Request to add something like "Auth failed from IP" log report for built-in VNC server
In environment with needs of public accessible VNC ports there is no logs or other registered events about authentication failures to analyze and/or integrate it to automated services like fail2ban ans so on.
Thus the built-in VNC service is vulnerable to brutforce attacks and in combination with weak built-in VNC-auth scheme can be a security vulnerability.
Adding a simple log record like "QEMU VNC Authentication failed 192.168.0.5:5902 - 123.45.67.89:7898" will permit to quickly integrate it to fail2ban system.
Note that any use of the built-in VNC-auth scheme is always considered a security flaw. It should essentially never be used, especially not on any public internet facing service, even if fail2ban were able to be used.
A secure VNC server should use the VeNCrypt extension which enables TLS, with optional client certificate validation as an auth mechanism. Once you have TLS enabled, you can also then enable the SASL auth mechanism to further authenticate clients using Kerberos or PAM, or other SASL plugins.
That's not to say we shouldn't emit a log message, suitable for consuming from fail2ban, as remote clients can still trigger a CPU denial of service by repeatedly connecting even if they ultimately always fail authentication.
On Wed, 8 May 2019 at 14:23, Daniel Berrange <email address hidden> wrote:
>
> Note that any use of the built-in VNC-auth scheme is always considered a
> security flaw. It should essentially never be used, especially not on
> any public internet facing service, even if fail2ban were able to be
> used.
Should we deprecate-and-remove the feature, then ?
thanks
-- PMM
The challenge is that this is the only auth scheme defined by the VNC protocol, aside from no-auth.
If we removed it, we'd no longer be compatible with the standard VNC protocol. We'd be making use of the TLS/SASL extensions mandatory if users want auth. This could ultimately push people to turn off auth altogether which is even worse.
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/170
|