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