Limit number of API access per seconds

[bgme_one]

Hi,

I'm using vert.x as a HTTP server for some API.

The API first requires a login, which in turn sends a session token, and further communication is done based on that token.

The API is basically accessed from an Android app but I'm afraid some users will override the app and abuse the API.

Anyone knows how can I limit API calls (besides the login) per time frame (say not more than 1 per second).

Is there some vert.x property/3rd party/known pattern for this problem?

Thanks

[bytor99999]

Well, not sure about Http calls. But in Sockets or Web Sockets you have a connection which you can start a timer at the moment the connection is made. Say for 10 seconds, and the callback of the timer would close the socket. Unless the client sends in a authentication message that passes within the 10 seconds. In that last case the timer would be cancelled. However http calls are not like that. Vert.x does not have anything built in. But you can always validate and check the message first thing. As whatever solution you find would be some sort of validation/filter anyway. You can't stop them from hitting your server, but you can block as early as you can.

Hope that helps

Mark

[Josh Kamau]

I normally put my application behind apache http server and then use mod_evasive to limit the hits on apache.

Josh

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bgme_one]

Thanks, but what prevents an attacker to authenticate once and then send endless socket requests?

Eyal

[Nate McCall]

HTTP rate limiting on anything more than a moderate scale is done via
distributed counters of some sort.

I would recommend either the Redis or memcached modules to start
experimenting. The pattern itself is pretty simple: generally just the
current access count divided by session start time (most likely
storing the session info in the same system at that point).

Whichever direction you go spend some time to understand the
operational characteristics of these systems, their failure scenarios
and the tradeoffs they have made to achieve their throughput. The
amount of complexity they introduce is not to be taken lightly.

[bytor99999]

If an attacker can login and authenticate, then you have huge problems. Meaning they can endlessly hit it or other issues. I have a validation service which is the next step. If the message isn't one in the validation service message types then it stops there.

Mark

[Frank Reiter]

On Tue, Mar 11, 2014 at 8:50 AM, bgme_one <ey.s...@gmail.com> wrote:

Thanks, but what prevents an attacker to authenticate once and then send endless socket requests?

You cannot stop them from making endless requests.  All you can do is choose what to do about it.

If all api calls are handled by the same verticle, it is fairly straight forward to check, for example, how long ago the third most recent call from that same user was, and if it was less than 3 seconds ago simple drop the message or reply with an error.  This arbitrarily chosen number of 3 allows for a little bursting, or some jitter in round trip time.  Adjust as seems best.

Frank.

[Tim Fox]

Throttling Http requests per source should be pretty straightforward with Vert.x.

You have access to the remoteAddress() on the HttpServerRequest, so you can maintain a Map of <address, bucket>

Where bucket maintains a count of tokens, e.g. using token bucket algorithm.

As a request comes in calculate the time since the last request and add a number of tokens depending on the throttle rate. If there are sufficient tokens allow the request if not disallow it.

[Frank Reiter]

On Tue, Mar 11, 2014 at 9:45 AM, bytor99999 <bytor...@gmail.com> wrote:

If an attacker can login and authenticate, then you have huge problems. Meaning they can endlessly hit it or other issues.

This isn't avoidable.  If his android app can login and authenticate, then a moderately sophisticated attacker can analyse that process and duplicate it in a malicious app.  It isn't uncommon for popular games which trust the client side app to be hacked to allow cheating.

You can avoid that latter scenario by making the app nothing more than a dumb client.  But you can't prevent the login process from being reimplemented.

Frank.

[bgme_one]

Ok, thanks all.

So I'll check these 2 paths:

1. Place the verticle's behind Apache configured to block fast hits.

2. Implement the solution myself using remoteAddrress property of a request. The only difficulty here the decision on whether:

  a. Implement a simple solution which will run on each verticle node locally.

  b. Implement a centralized solution based on a common cache.

Thanks !

Eyal

[Frank Reiter]

Note that you can distribute you rate limit processing and still share the data between nodes using hazelcast, which is included in vert.x.

Also, I wonder whether ip address based rate limiting might lead to problems when ISPs put thousands of users behind one address using NAT.  I am not sure how common that is these days.  If you are only concerned about authenticated requests, you might be better off limiting by user.  If you are concerned about being overwhelmed by unauthenticated requests, ip address is really your only choice.

Frank.

--