46 ms·
Rack Attack: Protection from abusive clients
- noonespecial 13y agoNice. 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.
- sbarre 13y agoHaha I also saw the kickstarter.com domain and thought: "tell me more about this!" probably thinking the same as you..
- toomuchtodo 13y agoImagine my dismay when I clicked through and read, "Oh, a web request client".
- hobs 13y agoI was about to donate a toe.
- jgj 13y agoMy wallet nearly hit me in the face such was its velocity upon breach of my pocket.
- arkitaip 13y agoSounds like you need protection from your own wallet!
- tcdent 13y agoYeah, 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.
- Samuel_Michon 13y agoThat, dear sir, was a beautifully crafted sentence. I had to reread it a couple of times to find out what the hell it meant.
- fduran 13y agoiptables 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.
- pyre 13y ago| blocking ports where there are no services doesn't | do much True, but it can be a useful 'just in-case' against things listening on ports that you were unaware of. It's obviously bad for you not to know about services that are listening on your box, but you could view it as a safety net.
- SeoxyS 13y agoA 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 13y ago
- umsm 13y agoThis seems like a vulnerability in their implementation: "configure your proxy to set the X-Forwarded-For header with the source IP"
- rrouse 13y agoThat'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.
- mh- 13y agoif you're behind a reverse proxy (or load balancer, etc.) one should normally have [firewall] rules to ensure that only these proxy hosts can even connect to your httpd. you also can configure your edge proxies to ignore X-Forwarded-For, or at least move it to another untrusted header if you want to preserve its contents. there's an nginx module (has to be compiled in) that lets you whitelist hosts which can send X-Forwarded-For, and turns that into the actual remote address provided to your upstreams. http://wiki.nginx.org/HttpRealipModule http://wiki.nginx.org/HttpRealipModule | http://nginx.org/en/docs/http/ngx_http_realip_module.html http://nginx.org/en/docs/http/ngx_http_realip_module.html
- michaelbuckbee 13y agoMaybe 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?
- daniloassis 13y agoProbably. It's a good way when you don't have privilege access to the server OR skills to do it manually on Nginx etc.
- samstokes 13y agoIt 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.
- toomuchtodo 13y agoMost times your firewall and router aren't doing layer 7/application level inspection/actioning. If Rack::Attack can handle it efficiently, its the easy way to go.
- sc00ter 13y agoThink of it as defense-in-depth. This allows higher-level, but more sophisticated rules, while your lower layers provide simpler but lower overhead filtering. Hopefully abusive requests never reach this thanks to your router / firewall / web server rules, but if they do, this will help keep things in check.
- jwilliams 13y agoMy 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/rack/attack/cache.rb https://github.com/kickstarter/rack-attack/blob/master/lib/r... 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 13y agoI 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 13y agoAs some of the others said, I see this as complementary, since you can deal with logic on Layer 7 with ease.