

Rack Attack: Protection from abusive clients - ktheory
http://www.kickstarter.com/backing-and-hacking/rack-attack-protection-from-abusive-clients

======
noonespecial
Nice. I was really hoping it protected me from a very different kind of
"abusive client" though. I guess there are somethings that even in ruby you
can't do easily.

~~~
jgj
My wallet nearly hit me in the face such was its velocity upon breach of my
pocket.

~~~
tcdent
Yeah, double confusing. After realizing it wasn't _that_ kind of client it
still took me a bit to realize it wasn't a fundraiser, either.

------
fduran
iptables can limit the number of connections per ip in a "cheap" (fast/early)
way. In fact is my #1 use of iptables since blocking ports where there are no
services doesn't do much.

~~~
SeoxyS
A much more common use of iptables for me is to limit outside traffic to port
21, 80, and 447, while letting whitelisted internal hosts use every other
ports, for other services used internally. We can then run those services
without authentication, and have much less exposure in case of an attack (the
only thing whose security we must trust is iptables, ssh, our HTTP web
server.)

~~~
count
Why would you run them without authentication? One mistake in your iptables
shouldn't instantly compromise your operation...

Best practice is 'defense in depth', not 'we'll just lock down the perimeter'.

------
michaelbuckbee
Maybe I'm missing something, but this seem like something that would only be
useful in situations where you don't have access to anything "closer" to the
network requests (router, firewall, webserver) that you can tweak to handle
these types of things.

So it's something that's good for Heroku apps?

~~~
samstokes
_It allows whitelisting... based on arbitrary properties of the request._

So if your user authentication code was also a Rack middleware, and you
inserted Rack::Attack after it in the middleware stack, you could rate limit
based on user account as well as IP address. That would be harder to do at the
firewall or web server level.

This isn't for preventing DOS attacks (for which you'd want to completely
avoid hitting application code), it's just for preventing unauthorised or
excessive usage.

------
jwilliams
My first question is how this works when you have more than one server.

It's not mentioned in the article, but this implementation uses the standard
Rails Cache:

[https://github.com/kickstarter/rack-
attack/blob/master/lib/r...](https://github.com/kickstarter/rack-
attack/blob/master/lib/rack/attack/cache.rb)

There are particular hooks in there for Redis. So if you've got "n" servers,
it seems the preferred approach is to use a central Redis store.

------
gingerlime
I used fail2ban to block abusive ips (based on string matching of specific
errors in our logs). This seems like an interesting alternative though to keep
things under one roof.

~~~
scott_karana
As some of the others said, I see this as complementary, since you can deal
with logic on Layer 7 with ease.

------
umsm
This seems like a vulnerability in their implementation: "configure your proxy
to set the X-Forwarded-For header with the source IP"

~~~
rrouse
That's pretty common practice so you don't get the IP of the machine your web
server is on passed to the app instead of the user's ip.

