Live data from Hacker News

DDoS protection

wiki.hetzner.de

151–160 of 175 posts

Re: DDoS protection

#151
post #13

I'm from Germany but Online.net is the way better alternative to Hetzner for me. Server grade hardware, cheaper, no compromises, internal network, etc. etc. I think they even hired a lot new support people recently so you get an answer pretty fast. Hetzner always has this "cheap feeling" even though the hardware looks good on paper.

https://www.ssllabs.com/ssltest/analyze.html?d=www.online.ne...

why is this downvoted? This is a valid concern... why trust a hosting company which cannot handle SSL well enough?

Re: DDoS protection

#152
post #150
post #76

Earlier quoted context omitted.

Except MiTM is used primarily, if not exclusively, in attack scenarios. Otherwise any third-party you use as a website owner is a MiTM.

If they’re stripping encryption and reapplying they’re MITM. Seems pretty straightforward.

It's amazing how you can redeclare the meaning of words and distort reality just to fit your narrative.

Stripping encryption implies that there was, at some point, some sort of encryption between the browser and the website itself, which there never ever was. In the Cloudflare architecture the browser never ever interacts with the website, always with the Cloudflare servers. When you've got the small lock, it never implied that you were connecting to the website, but always that you were connecting to what lies behind the domain name, which is the Cloudflare servers. As an additional point, the website owner has always agreed to use this architecture; they're not somehow victim of some kind of attack from a spooky middleman. They ask (heck, some of them even pay) for it. It is part of the way they want to serve content.

You should tone down the sentimental analysis and keep to the facts. Cloudflare is a reverse proxy service the website owner uses; it is part of their infrastructure.

Re: DDoS protection

#153

Earlier quoted context omitted.

Simple, Hetzner directly buys at transit wholesale prices.

Amazon peers extensively, so they don't even pay for (most of) the traffic! (Not on a recurring basis anyways -- yes, there's the one-time capital costs and such.)

Peering has recurring costs too, it's just not going to the other peer (generally), the recurring costs are for things like space at the exchange, exchange fees for dedicated circuits to the peer, etc.

Re: DDoS protection

#154
post #83
post #61

Earlier quoted context omitted.

This was never the intention. Part of the problem is inertion - cf operates large and complex application that was designed back when we had only a handful of customers. Part of the problem is technical - the privacy-centric anti-abuse technologies don't exist yet. Please do help us fix this. Report issues, help us understand when we have incorrect IP reputation. Help us find captcha accessibility problems. And maybe…

Problem is, your "incorrect IP reputation" concept is fundamentally flawed. As an example, I noticed that most VPN exit nodes have "incorrect IP reputation", which means if I want to browse the internet without my government spying on me, I have to wade through all your CAPTCHAs.

There is probably no solution to this problem. Criminals regularly use those same services you're using.

Cloudflare's job is to block potential attacks, and blocking or CAPTCHA-restricting a subnet tied to a large number of attacks against their infrastructure seems reasonable.

Either switch VPN providers, or deal with the CAPTCHAs.

Re: DDoS protection

#155
post #75

Earlier quoted context omitted.

As a site operator you basically must use Cloudflare and highly aggressive policies regarding Tor. I like Tor as a concept, the problem is that there is no way to stop people massively abusing Tor. Whatever you want - nazi/hate speech, swatting, trolling, DDoS (by hitting expensive render paths or by forcing cache bypasses) - operate any kind of site with user interactions and you will get messed around with by mostl…

As a site operator, I have Tor (T1) whitelisted on all of my CloudFlare websites and have no additional spam problems or anything else. CloudFlare doesn't even catch all of my malicious traffic (spammers, mostly) -- even StopForumSpam doesn't do a 100% perfect job.

Counter-anecdote: I run a fairly small community and deal with an absurd amount of problems (spam, child pornography, threats, attempted attacks) sourcing from Tor and VPNs like PrivateInternetAccess.

I'm very glad CF exists. It certainly doesn't catch all bad traffic in my case either, but it helps. I don't think any cloud security service can ever stop all spam or bot activity.

Re: DDoS protection

#156
post #141
post #86

Earlier quoted context omitted.

Using a massively shared IP space of any kind is only available by submitting to a poor experience. Nobody is saying "hey this guy has privacy, lets make this experience a pain in the arse". They're saying "Man this set of specific IPs are really hammering my system looking for WordPress exploits and we're not even running that". To treat Tor better than regular traffic would be to discriminate against Tor, which wou…

So carrier-grade NATs should also be captchad to hell. Somehow, they aren’t. Very mysterious, indeed.

Pure rough estimates, but consumer ISP subnets are probably ~1-3% malicious, while with Tor's rotating IPs, if you look over the past 5 years odds are at least 40% of exit node IPs have been associated with malicious activity at least once.

It makes perfect sense to add additional verification challenges for Tor users.

Also, anecdotal, but I work in infosec for a large US company and see a lot of traffic and read a lot of logs every day. The majority of all spam, fraud, and scan activity comes from Tor, or consumer-advertised VPN services, or various European VPSs. Residential ISPs (excluding Chinese and Russian ones) make up almost no part of it, relative to those others.

I'm pretty sure Cloudflare's challenge criteria is sourced from real data they've generated from traffic they've seen. They aren't trying to single out Tor users.

Re: DDoS protection

#157
post #98

Earlier quoted context omitted.

So they're willing to provide a SLA with 4 hrs of downtime every month. This does not however mean that you will have 4 hrs of down-time per mont - it's a managed risk. Also, depending on the nature of your application, you can often get away with that kind of downtime. Something trivial (yet extremely popular) like Twitter had lots of down-time and it made the users love the service even more.

Huh, never heard of that. Care to explain how that happened?

The claim that downtime "made the users love the service even more" is probably a stretch, but Twitter's error page became a bit of a phenomenon in its own right for a while:

http://www.theatlantic.com/technology/archive/2015/01/the-st...

I think the main lesson here is that your error messages are part of your UX and need to be treated as such.

Re: DDoS protection

#158
post #130

Earlier quoted context omitted.

It seems you’re affiliated with Sucuri, I wonder why you don’t include that in your profile?

Because I am not. Just like their service and use it along with CloudFlare (which I always recommend).

It’s just surprising when more than two thirds of all the comments you ever made were somehow telling people to use it.

That just creates a wrong impression.

Re: DDoS protection

#159
post #130

Earlier quoted context omitted.

Because I am not. Just like their service and use it along with CloudFlare (which I always recommend).

It’s just surprising when more than two thirds of all the comments you ever made were somehow telling people to use it. That just creates a wrong impression.

I can see that. I just tend to engage on threads about ddos/security where I share what I do and tools I use.

Re: DDoS protection

#160
post #152
post #150

Earlier quoted context omitted.

If they’re stripping encryption and reapplying they’re MITM. Seems pretty straightforward.

It's amazing how you can redeclare the meaning of words and distort reality just to fit your narrative. Stripping encryption implies that there was, at some point, some sort of encryption between the browser and the website itself, which there never ever was . In the Cloudflare architecture the browser never ever interacts with the website, always with the Cloudflare servers. When you've got the small lock, it never…

> In the Cloudflare architecture the browser never ever interacts with the website, always with the Cloudflare servers.

Indeed.

It's almost as if metaphorically speaking they were standing there between them... like a man... in the middle...

Post reply on HN