Per connection limits?

[serkandurusoy]

Per IP limits are great but what happens when you create an app, get a company with 10,000 employees to use that app, they share a common outgoing IP address?

In such a case, sikka will think there are thousands of requests comming from that IP and per IP limits may kick in.

So if I'm not mistaken and this indeed is tha case, can we make Sikka to apply limits on a per connection basis as well?

[arunoda]

Per connection can be applied. But then, someone can send a DOS with few load but with multiple set of connections. So, the answer for this is whitelisting some IPs or Users.

Shall we carry on this discussion on the other thread.

[serkandurusoy]

As much as whitelisting would a great feature, I think you should reconsider this too.

There are other scenarious that this could be utilized. For example:

A small company is my apps user. They have 20 users. One disgruntled employee starts an attack so that nobody in that company can use the app.

Or a hacker starts dos attacks to my "social network app" from internet cafes and public wifi access points. IP addresses get blocked thereore noone in those areas can access my app, can't understand why they have to see such a warning message and finally stop using my app.

But you are also correct that an attacker can start multiple conections. On the other hand, it is harder than doing the whole thing from a single console.

There is no perfect single way to stop an attack for sure.

But, I think a per connection configuration would give that decision to our hands so that I can decide for my apps own use case and its attack situation to configure both per IP and per connection (or perhaps even per userId & per anonymous user ) limits.

[arunoda]

I think we already have this feature.

When we block the IP. Next time a user visit the site.
We ask him to enter the captha.
Then we identify that user as a human and save a cookie into his browser.
So, this human can use the app regardless of the IP block.
(This human also have a limit)

On Sat, Mar 28, 2015 at 6:45 PM Serkan Durusoy notifications@github.com
wrote:

As much as whitelisting would a great feature, I think you should
reconsider this too.

There are other scenarious that this could be utilized. For example:

A small company is my apps user. They have 20 users. One disgruntled
employee starts an attack so that nobody in that company can use the app.

Or a hacker starts dos attacks to my "social network app" from internet
cafes and public wifi access points. IP addresses get blocked thereore
noone in those areas can access my app, can't understand why they have to
see such a warning message and finally stop using my app.

But you are also correct that an attacker can start multiple conections.
On the other hand, it is harder than doing the whole thing from a single
console.

There is no perfect single way to stop an attack for sure.

But, I think a per connection configuration would give that decision to
our hands so that I can decide for my apps own use case and its attack
situation to configure both per IP and per connection (or perhaps even per
userId & per anonymous user ) limits.

—
Reply to this email directly or view it on GitHub
#7 (comment).

[serkandurusoy]

Oh, so you not only filter based on IP addresses but also create and filter based on cookies!

Hmm. It's nice.

And I guess you are talking about https://github.com/meteorhacks/sikka/blob/master/lib/server/core.js when you say you are also tracking humans with some limits.

OK, I'll think of other ways people may get around this or devs need some other relaxations due to use cases. :)

I am really very interested in this package because two years ago, I had to shut down a startup business due to organized trolling and gaming activity which we could not fight in the end. And in fact, I'm thinking of getting that startup back up as a mobile-first app (this time on meteor as tech stack)

[arunoda]

Great. I'm doing to do a new release around next week with some features on here as well as more docs.
Yeah! Ping me with more cases.