diff options
Diffstat (limited to 'results/classifier/zero-shot/105/socket/1828207')
| -rw-r--r-- | results/classifier/zero-shot/105/socket/1828207 | 52 |
1 files changed, 52 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/105/socket/1828207 b/results/classifier/zero-shot/105/socket/1828207 new file mode 100644 index 000000000..d30dcee1f --- /dev/null +++ b/results/classifier/zero-shot/105/socket/1828207 @@ -0,0 +1,52 @@ +socket: 0.670 +vnc: 0.624 +network: 0.593 +device: 0.527 +other: 0.419 +semantic: 0.300 +mistranslation: 0.280 +instruction: 0.212 +assembly: 0.166 +KVM: 0.165 +boot: 0.153 +graphic: 0.113 + +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 + + |