qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 6/6] vnc: track & limit connections


From: Gonglei
Subject: Re: [Qemu-devel] [PATCH 6/6] vnc: track & limit connections
Date: Fri, 17 Oct 2014 14:34:07 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1

On 2014/10/16 18:46, Gerd Hoffmann wrote:

>   Hi,
> 
>>> I try to prevent that by dropping the *oldest* connection, so you have a
>>> chance to connect even if a unprivileged attacker tries to use up all
>>> connection slots.
>>
>> Lets say the limit is 5. The bad guy has 5 open idle connections.
>> The good guy opens a new one and pushes off one of the bad guy's
>> connections. Fine so far. The bad guy though can simply open 5 more
>> connections and he'll push the good guy's connection off again.
> 
> Correct.  It can't fully prevent the attack, but makes it harder to pull
> off.  Just having $limit idle connects isn't enough any more, the bad
> guy has to constantly bomb qemu with vnc connect requests, hoping this
> kicks out the good guy before it managed to authenticate.  The chances
> for the good guy are a bit better and it is also more likely that the
> attack sets off alarms in network monitoring.
> 

Hi,

Happy that I don't miss this patch series and conversation.
I have a approach to prevent the brute force attack (which
had been tested in my team). Firstly, we must set password for
vnc server for security. Secondly, the DoS may bomb qemu
with vnc connect requests, trying to decrypt password at present.

If we set the max trying times, and then
There are some concepts:
 - INTERVAL_TIME: a time window that user can connnet vnc server
 - REJECT_TIME: the time of reject any connection
 - MAX_TRY_TIMES: the times that user can connect vnc server in INTERVAL_TIME,
   if attach the MAX_TRY_TIMES, the server will lock, any user can not connect 
again
   before REJECT_TIME attached. The old connected client will not be influenced.

Do you think it make sense if I post this approach in upstream ? Thanks.

Best regards,
-Gonglei





reply via email to

[Prev in Thread] Current Thread [Next in Thread]