Rack Attack: Protection from abusive clients
kickstarter.com
Rack Attack: Protection from abusive clients
1–10 of 28 posts
Re: Rack Attack: Protection from abusive clients
#2Nice. 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.
Re: Rack Attack: Protection from abusive clients
#3Nice. 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.
Haha I also saw the kickstarter.com domain and thought: "tell me more about this!" probably thinking the same as you..
Re: Rack Attack: Protection from abusive clients
#4iptables 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.
Re: Rack Attack: Protection from abusive clients
#5iptables 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.
| blocking ports where there are no services doesn't
| do much
Re: Rack Attack: Protection from abusive clients
#6iptables 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.
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.)
Re: Rack Attack: Protection from abusive clients
#7iptables 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.
Yeah, iptables works great for that.
I also like nginx's limit_zone module. You can put limit_zone in the proxy stanza, and only throttle dynamic requests without throttling access to fast static files.
We often use Rack::Attack to throttle particular HTTP paths differently. Say, the homepage isn't throttled, but the login action is. That layer 7 knowledge is Rack::Attack's main advantage.
As I say in the README, Rack::Attack is complementary to iptables and the limit_zone module.
Re: Rack Attack: Protection from abusive clients
#8Nice. 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.
My wallet nearly hit me in the face such was its velocity upon breach of my pocket.
Re: Rack Attack: Protection from abusive clients
#9This seems like a vulnerability in their implementation: "configure your proxy to set the X-Forwarded-For header with the source IP"
Re: Rack Attack: Protection from abusive clients
#10iptables 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.
| 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.
Agree, I also block all unused incoming ports as a safety net as you say.