Hacker News Reader

Comment by blamarvt | Hacker News Reader

The DDoS tactics may have changed but the initial attack [0] was from all non-Chinese IPs who were visiting Chinese websites. That's what makes this attack so difficult to block -- requests aren't being made from Chinese IPs but rather from everwhere else.

[0] - http://insight-labs.org/?p=1682

View on HN

Maybe a naive question, but in the original attack, couldn't the 'bad' requests have been identified using the referrer?

Yes, that's one of the method that was used: from https://news.ycombinator.com/item?id=9284226 :

> The first round was cross-domain JavaScript, stopped with an "alert()". Second round was cross-domain <img>, stopped with referrer. Third was DDoS-ing GitHub Pages. Fourth is the ongoing TCP SYN Flood attack.

In that case, why is https://github.com/greatfire/ still returning the alert(..) js when not coming from Baidu?

> > The first round was cross-domain JavaScript, stopped with an "alert()".

> Second round was cross-domain <img>, stopped with referrer.

It does not mention that the alert() used the referrer.

Apologies if I'm being dense, but is there some technical reason why it does not use the referrer to selectively block this traffic rather than blocking it for everyone?

The content doesn't seem to be blocked if you remove the trailing slash. I don't really have an answer for you aside from that though.

E.g.:

- This works: https://github.com/greatfire

- This doesn't: https://github.com/greatfire/

So far as I know, most links (external or internal) to a Github user's page do not use the trailing slash, so the effects would presumably be minimal.

Parsing the referrer would still require some work from their servers right?

Sure. I suppose that could be the reason. However, something like HA proxy[1] and (IIRC) CDNs like Akamai can be configured to inspect the headers and take various action.

[1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html...

Reply on news.ycombinator.com