On 2014/10/21 17:35, Gerd Hoffmann wrote:
> Hi,
>
>> Yes. But I think it is not a big problem, when the REJECT_TIME is over,
>> the good guys can connect vnc successfully immediately.
>> Or maybe we just lock those guys with "the same Source IP address" ?
>
> Better. Question is whenever we r
Hi,
> Yes. But I think it is not a big problem, when the REJECT_TIME is over,
> the good guys can connect vnc successfully immediately.
> Or maybe we just lock those guys with "the same Source IP address" ?
Better. Question is whenever we really want implement those schemes
within qemu or leav
On 2014/10/21 16:57, Gerd Hoffmann wrote:
> On Di, 2014-10-21 at 14:06 +0800, Gonglei wrote:
>> On 2014/10/20 15:02, Gerd Hoffmann wrote:
>>
>>>
>>> Hi,
>>>
If we set the max trying times, and then
There are some concepts:
- INTERVAL_TIME: a time window that user can connnet vnc
On Di, 2014-10-21 at 14:06 +0800, Gonglei wrote:
> On 2014/10/20 15:02, Gerd Hoffmann wrote:
>
> >
> > Hi,
> >
> >> 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 reje
On 2014/10/20 15:02, Gerd Hoffmann wrote:
>
> Hi,
>
>> 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 conn
Hi,
> 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 MA
On 2014/10/17 14:38, Daniel P. Berrange wrote:
> On Fri, Oct 17, 2014 at 02:34:07PM +0800, Gonglei wrote:
>> 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 atta
On Fri, Oct 17, 2014 at 02:34:07PM +0800, Gonglei wrote:
> 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.
>
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.
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 on
On 10/15/2014 06:19 AM, Gerd Hoffmann wrote:
> Also track the number of connections in "connecting" and "shared" state
> (additionally to "exclusive" state). Apply a configurable limit to
s/additionally to/in addition to the/
> these connections.
>
> The logic to apply the limit to connections
Hi,
> > The logic to apply the limit to connections in "connecting" state (this
> > is the state you are in *before* successfull authentication) is
> > slightly different: A new connect kicks out the oldest client which is
> > still in "connecting" state. This avoids a easy DoS by unauthentica
On Wed, Oct 15, 2014 at 04:19:29PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > The logic to apply the limit to connections in "connecting" state (this
> > > is the state you are in *before* successfull authentication) is
> > > slightly different: A new connect kicks out the oldest client which is
On Wed, Oct 15, 2014 at 02:19:45PM +0200, Gerd Hoffmann wrote:
> Also track the number of connections in "connecting" and "shared" state
> (additionally to "exclusive" state). Apply a configurable limit to
> these connections.
>
> The logic to apply the limit to connections in "shared" state is p
Also track the number of connections in "connecting" and "shared" state
(additionally to "exclusive" state). Apply a configurable limit to
these connections.
The logic to apply the limit to connections in "shared" state is pretty
simple: When the limit is reached no new connections are allowed.
15 matches
Mail list logo
