On 10/8/13 5:20 PM, Melanie wrote:
People like us have the protection in the proxy and need to turn the
feature off. Not a problem for me, I'm aware of it, but my concern
was for those who didn't listen to me tell them "Dont' blindly reuse
configs"
If they are too stupid or foolish or arrogan
People like us have the protection in the proxy and need to turn the
feature off. Not a problem for me, I'm aware of it, but my concern
was for those who didn't listen to me tell them "Dont' blindly reuse
configs"
Melanie
___
Opensim-dev mailing list
Another note, I can probably expand the DOS protection class to
identify X sessions and establish a maximum number of sessions pretty
easily and with really low overhead.I have not yet.. just X
requests in Y seconds and Z seconds to unblock.
I may do that later this week. (but won't have it
LoginService, Very much agreed. Though, I figured I'd give people 5
attempts in 10 seconds before sending them on their way in case they
improperly type their password a few times quickly.
Inventory Service, Also very much agreed. There is no DOS
protection on that service at the moment.
T
The login server should only ever see one connection per client, any more is
most likely a DOS.
Services that are called by regions are way more critical, as they get all
requests from a few entities only. The inventory service, for instance, can't
be rate limited because a single login creates
I'm sure you could configure nginx to send the X-Forwarded-For header
to the OpenSim based service and then enable the
DOSAllowXForwardedForHeader in the robust.ini to receive the power of
the 'per service' rate limiting while also having the protection at
the proxy level.That said, I'm happy
Yes, just confirmed it:
http://www.networkinghowtos.com/howto/set-the-x-forwarded-for-header-on-a-nginx-reverse-proxy-setup/
Documentation on how to set up X-Forwarded-For in nginx
Best Regards
Teravus
On Tue, Oct 8, 2013 at 12:10 PM, Teravus Ovares wrote:
> I'm sure you could configure ng
I had a look at the Robust.ini.example earlier and I found the instructions
to be clear and straight forward, I am glad you did infact allow this to be
completely disabled, at OSgrid we use nginx as a reverse proxy and also to
do DoS protection and load balancing, without the options to disable thi
Just to be clear, and comment/answer some questions.
I did add the DOS protection variables to the Robust.ini.example in
the [LoginService] section. The Rate Limit code does 'per connection'
velocity counts. The default rate setting is 5 requests in 10
seconds.If you have a transparent prox
Does this class the same as what i ever tried with apache.
With apache it worked, but as soon you used groups and the DDOS apaceh
filter where set too low it got jammed and stuck.
But if you set it to high the use is possible zero. Not saying its
useless. But maby good to understand how it works
As I have often been told by you, Melanie, if I am upgrading and not
auditing, adjusting, and testing my configs in accordance with changes, I'm
doing it wrong.
I think that statement probably applies more to those running larger
concerns than anyone else.
Honestly, Teravus typically does a bette
I'm worried that people with larger installations will see service failures
because legit traffic is seen as abusive. This could cause issues for the
lerger grids out there. I don't believe that whatever tenuous protection this
may offer for small grids and standalones outwieghs the potential se
At 11:00 08/10/2013, Teravus Ovares wrote:
Just for the sake of getting something up
there, I set the defaults to something sane, however they may not work
for everyone, so it may be wise to take a look at the new
configuration options in the [LoginService] section of your
bin/Robust.ini.example
I'm not a dev and certainly not anybody special, but this has been needed
for some time.
Thank you Teravus for recognizing the need, and I hope that this can be
implemented somehow even if it is not the default configuration.
On Tue, Oct 8, 2013 at 6:27 AM, James Stallings II <
james.stalli...@g
Also I might point out that this policy has rarely been adhered in the
past, and generally in cases where the practical operations impact is far
greater (HG).
Cheers
On Oct 8, 2013 2:40 AM, "Teravus Ovares" wrote:
> I understand what you're saying. It's hard to argue to leave
> people unpr
I understand what you're saying. It's hard to argue to leave
people unprotected from attacks, though.I'm certainly open to
making the defaults less protective, and, I'm concerned enough about
it that I'd prefer to leave some protection in place there.
What are your thoughts on that?
Bes
16 matches
Mail list logo
