<div dir="ltr">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 this completely it would have been a major problem moving forward.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 8, 2013 at 12:27 PM, Teravus Ovares <span dir="ltr"><<a href="mailto:teravus@gmail.com" target="_blank">teravus@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just to be clear, and comment/answer some questions.<br>
<br>
I did add the DOS protection variables to the Robust.ini.example in<br>
the [LoginService] section. The Rate Limit code does 'per connection'<br>
velocity counts. The default rate setting is 5 requests in 10<br>
seconds. If you have a transparent proxy, such as squid, you need<br>
to set DOSAllowXForwardedForHeader to true so that the code trusts the<br>
X-Forwarded-For header that your proxy adds to the headers. If you<br>
want to turn it off, set DOSMaxRequestsInTimeFrame = 0. If you<br>
want to allow individual clients to do 20 connections in 5 seconds,<br>
set DOSMaxRequestsInTimeFrame = 20 and DOSRequestTimeFrameMS = 5000.<br>
If you want to change how long individual connections are blocked<br>
when they go over the rate limit, change DOSForgiveClientAfterMS.<br>
<br>
Hopefully this helps get you started with the config options.<br>
<br>
One more thing, this DOS protector is configured and implemented 'per<br>
service', So, if it's implemented in the login service, it's not<br>
going to get triggered by the Group Service. If there's DOS<br>
protection on the Group Service and the login service, and a<br>
connection gets blocked on the login service, they'll still be able to<br>
access the Group Service because they're individually rate limited...<br>
This is for flexibility. Choosing what the best rate limit is<br>
cannot really be done server wide, it has to be based on the needs of<br>
the individual service and that's why it was implemented this way.<br>
At this point, the only major service that has rate limiting on by<br>
default is the login service.<br>
<br>
I'll be happy to answer more questions and discuss default settings.<br>
<br>
<br>
Best Regards<br>
<span class="HOEnZb"><font color="#888888"><br>
Teravus<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Tue, Oct 8, 2013 at 8:04 AM, James Stallings II<br>
<<a href="mailto:james.stallings@gmail.com">james.stallings@gmail.com</a>> wrote:<br>
> As I have often been told by you, Melanie, if I am upgrading and not<br>
> auditing, adjusting, and testing my configs in accordance with changes, I'm<br>
> doing it wrong.<br>
><br>
> I think that statement probably applies more to those running larger<br>
> concerns than anyone else.<br>
><br>
> Honestly, Teravus typically does a better job of coding than to produce work<br>
> that does not take such matters of scale into consideration.<br>
><br>
> I'm comfortable with whatever he chooses to do, and if it turns out it isn't<br>
> a case of 'one size fits all', I'll make adjustments accordingly.<br>
><br>
><br>
> On Tue, Oct 8, 2013 at 7:52 AM, Melanie <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> wrote:<br>
>><br>
>> I'm worried that people with larger installations will see service<br>
>> failures because legit traffic is seen as abusive. This could cause issues<br>
>> for the lerger grids out there. I don't believe that whatever tenuous<br>
>> protection this may offer for small grids and standalones outwieghs the<br>
>> potential service impairment it may cause for unsuspecting larger grids. Not<br>
>> every grid operator reads this list,<br>
>><br>
>> So I'd again suggest that we stick to the way we've always done it and<br>
>> make the default for new features be "off".<br>
>><br>
>> Melanie<br>
>><br>
>> On 8 Oct 2013, at 09:31, Teravus Ovares <<a href="mailto:teravus@gmail.com">teravus@gmail.com</a>> wrote:<br>
>><br>
>> I understand what you're saying. It's hard to argue to leave<br>
>> people unprotected from attacks, though. I'm certainly open to<br>
>> making the defaults less protective, and, I'm concerned enough about<br>
>> it that I'd prefer to leave some protection in place there.<br>
>><br>
>> What are your thoughts on that?<br>
>><br>
>> Best Regards<br>
>><br>
>> Teravus<br>
>><br>
>> On Tue, Oct 8, 2013 at 12:41 AM, Melanie <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> wrote:<br>
>> > Hi,<br>
>> ><br>
>> > in keeping with our SOP, the defaults provided should be emulating<br>
>> > the previous behavior, e.g. NO rate limiting.<br>
>> ><br>
>> > I would much appreciate if that procedure would be adhered to,<br>
>> > unless we vote to abandon it. Users could suffer because they don't<br>
>> > expect the default config to change on them.<br>
>> ><br>
>> > Cheers,<br>
>> ><br>
>> > Melanie<br>
>> ><br>
>> > On 08/10/2013 05:42, Teravus Ovares wrote:<br>
>> >> Hi there,<br>
>> >><br>
>> >> I just wanted to inform -dev that I added some rate limiting DOS<br>
>> >> protection classes to use to protect your opensim based services from<br>
>> >> rapid calling. At the moment, this will be most noticeable in the<br>
>> >> Login Service. I have, both as an example, and good practice,<br>
>> >> applied the Rate limit protection to the login service. There are<br>
>> >> new Configuration options in StandaloneCommon.ini and Robust.ini that<br>
>> >> control how the connections are rate limited and if trusts the<br>
>> >> X-Forwarded-For header. Just for the sake of getting something up<br>
>> >> there, I set the defaults to something sane, however they may not work<br>
>> >> for everyone, so it may be wise to take a look at the new<br>
>> >> configuration options in the [LoginService] section of your<br>
>> >> bin/Robust.ini.example and<br>
>> >> /bin/config-include/StandaloneCommon.ini.example AND/OR have<br>
>> >> discussions on what would be more sane default options. There's a<br>
>> >> chance that this could affect anyone, so don't neglect to take a look<br>
>> >> at it.<br>
>> >><br>
>> >> You may also notice messages on your console and in your logs like:<br>
>> >> 21:56:29 - [LOGINDOSPROTECTION]: client: 192.168.1.213 is blocked for<br>
>> >> 120000 milliseconds, X-ForwardedForAllowed status is False,<br>
>> >> endpoint:192.168.1.213<br>
>> >><br>
>> >> This is an example of the DOS Protection blocking a connection because<br>
>> >> the client went beyond the rate limit.<br>
>> >><br>
>> >> The rate limit is defined by X requests in Y period of time and is<br>
>> >> implemented in a rolling Y fashion. It also has a 'forget' period of<br>
>> >> time that will unblock the blocked user.<br>
>> >><br>
>> >> At this point, there's one implemented for XMLRPC handlers, one for<br>
>> >> GenericHTTPHandlers and a base class for StreamHandlers based on<br>
>> >> BaseStreamHandler.<br>
>> >><br>
>> >> If you are interested in the code changes, you can check the diff:<br>
>> >><br>
>> >> <a href="http://opensimulator.org/viewgit/?a=commitdiff&p=opensim&h=f76cc6036ebf446553ee5201321879538dafe3b2" target="_blank">http://opensimulator.org/viewgit/?a=commitdiff&p=opensim&h=f76cc6036ebf446553ee5201321879538dafe3b2</a><br>
>> >><br>
>> >> There's still more to do, and, here's a start to providing some<br>
>> >> modicum of protection on the services.<br>
>> >><br>
>> >> If you have any questions, feel free to reply and ask.. or send me an<br>
>> >> e-mail personally.<br>
>> >><br>
>> >> Thanks and Best Regards<br>
>> >><br>
>> >> Teravus<br>
>> >> _______________________________________________<br>
>> >> Opensim-dev mailing list<br>
>> >> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> >> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>> > _______________________________________________<br>
>> > Opensim-dev mailing list<br>
>> > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> ===================================<br>
> <a href="http://osgrid.org/" target="_blank">http://osgrid.org/</a><br>
> <a href="http://simhost.com" target="_blank">http://simhost.com</a><br>
> <a href="http://twitter.com/jstallings2" target="_blank">http://twitter.com/jstallings2</a><br>
><br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Michael Emory Cerquoni
</div>