Live data from Hacker News

Rack Attack: Protection from abusive clients

kickstarter.com

21–28 of 28 posts

Re: Rack Attack: Protection from abusive clients

#21
post #9

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

if 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://nginx.org/en/docs/http/ngx_http_realip_module.html

Re: Rack Attack: Protection from abusive clients

#22
post #8

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.

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

That, dear sir, was a beautifully crafted sentence. I had to reread it a couple of times to find out what the hell it meant.

Re: Rack Attack: Protection from abusive clients

#23
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...

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.

Re: Rack Attack: Protection from abusive clients

#25
post #3

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.

Haha I also saw the kickstarter.com domain and thought: "tell me more about this!" probably thinking the same as you..

I was about to donate a toe.

Re: Rack Attack: Protection from abusive clients

#26
post #10

Earlier quoted context omitted.

Agree, I also block all unused incoming ports as a safety net as you say.

Probably easier to just use a whitelist policy, no?

Of course; implementation of the idea is whitelist: allow used ports default policy deny all

Re: Rack Attack: Protection from abusive clients

#27
post #6
post #4

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.

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.)

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'.

Re: Rack Attack: Protection from abusive clients

#28

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.

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