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? Best Regards Teravus On Tue, Oct 8, 2013 at 12:41 AM, Melanie <mela...@t-data.com> wrote: > Hi, > > in keeping with our SOP, the defaults provided should be emulating > the previous behavior, e.g. NO rate limiting. > > I would much appreciate if that procedure would be adhered to, > unless we vote to abandon it. Users could suffer because they don't > expect the default config to change on them. > > Cheers, > > Melanie > > On 08/10/2013 05:42, Teravus Ovares wrote: >> Hi there, >> >> I just wanted to inform -dev that I added some rate limiting DOS >> protection classes to use to protect your opensim based services from >> rapid calling. At the moment, this will be most noticeable in the >> Login Service. I have, both as an example, and good practice, >> applied the Rate limit protection to the login service. There are >> new Configuration options in StandaloneCommon.ini and Robust.ini that >> control how the connections are rate limited and if trusts the >> X-Forwarded-For header. 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 and >> /bin/config-include/StandaloneCommon.ini.example AND/OR have >> discussions on what would be more sane default options. There's a >> chance that this could affect anyone, so don't neglect to take a look >> at it. >> >> You may also notice messages on your console and in your logs like: >> 21:56:29 - [LOGINDOSPROTECTION]: client: 192.168.1.213 is blocked for >> 120000 milliseconds, X-ForwardedForAllowed status is False, >> endpoint:192.168.1.213 >> >> This is an example of the DOS Protection blocking a connection because >> the client went beyond the rate limit. >> >> The rate limit is defined by X requests in Y period of time and is >> implemented in a rolling Y fashion. It also has a 'forget' period of >> time that will unblock the blocked user. >> >> At this point, there's one implemented for XMLRPC handlers, one for >> GenericHTTPHandlers and a base class for StreamHandlers based on >> BaseStreamHandler. >> >> If you are interested in the code changes, you can check the diff: >> http://opensimulator.org/viewgit/?a=commitdiff&p=opensim&h=f76cc6036ebf446553ee5201321879538dafe3b2 >> >> There's still more to do, and, here's a start to providing some >> modicum of protection on the services. >> >> If you have any questions, feel free to reply and ask.. or send me an >> e-mail personally. >> >> Thanks and Best Regards >> >> Teravus >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
