qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gonglei <arei.gonglei@huawei.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Huangweidong (C)" <weidong.huang@huawei.com>,
	"Huangpeng (Peter)" <peter.huangpeng@huawei.com>,
	qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 6/6] vnc: track & limit connections
Date: Fri, 17 Oct 2014 14:34:07 +0800	[thread overview]
Message-ID: <5440B85F.3060307@huawei.com> (raw)
In-Reply-To: <1413456389.18160.1.camel@nilsson.home.kraxel.org>

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	other threads:[~2014-10-17  6:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-15 12:19 [Qemu-devel] [PATCH 0/6] vnc: add support for multiple vnc server instances Gerd Hoffmann
2014-10-15 12:19 ` [Qemu-devel] [PATCH 1/6] vnc: remove vnc_display global Gerd Hoffmann
2014-10-15 12:19 ` [Qemu-devel] [PATCH 2/6] vnc: remove unused DisplayState parameter, add id instead Gerd Hoffmann
2014-10-15 12:19 ` [Qemu-devel] [PATCH 3/6] vnc: switch to QemuOpts, allow multiple servers Gerd Hoffmann
2014-10-15 12:19 ` [Qemu-devel] [PATCH 4/6] vnc: allow binding servers to qemu consoles Gerd Hoffmann
2014-10-15 12:19 ` [Qemu-devel] [PATCH 5/6] vnc: update docs/multiseat.txt Gerd Hoffmann
2014-10-15 12:19 ` [Qemu-devel] [PATCH 6/6] vnc: track & limit connections Gerd Hoffmann
2014-10-15 12:31   ` Daniel P. Berrange
2014-10-15 14:19     ` Gerd Hoffmann
2014-10-15 14:39       ` Daniel P. Berrange
2014-10-16 10:46         ` Gerd Hoffmann
2014-10-17  6:34           ` Gonglei [this message]
2014-10-17  6:38             ` Daniel P. Berrange
2014-10-17  6:54               ` Gonglei
2014-10-20  7:02             ` Gerd Hoffmann
2014-10-21  6:06               ` Gonglei
2014-10-21  8:57                 ` Gerd Hoffmann
2014-10-21  9:10                   ` Gonglei
2014-10-21  9:35                     ` Gerd Hoffmann
2014-10-21 10:32                       ` Gonglei
2014-10-15 14:51   ` Eric Blake
2014-10-15 12:32 ` [Qemu-devel] [PATCH 0/6] vnc: add support for multiple vnc server instances Daniel P. Berrange
2014-10-15 14:29   ` Gerd Hoffmann
2014-10-15 14:41     ` Daniel P. Berrange
2014-10-15 12:51 ` Daniel P. Berrange
2014-10-15 14:30   ` Gerd Hoffmann
2014-10-15 14:48 ` Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5440B85F.3060307@huawei.com \
    --to=arei.gonglei@huawei.com \
    --cc=aliguori@amazon.com \
    --cc=dgilbert@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=peter.huangpeng@huawei.com \
    --cc=qemu-devel@nongnu.org \
    --cc=weidong.huang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).