gopi_ar

"So today, on the first day of our Birthday Week celebration, we make it official for all our customers: Cloudflare will no longer terminate customers, regardless of the size of the DDoS attacks they receive, regardless of the plan level they use. And, unlike the prevailing practice in the industry, we will never jack up your bill after the attack.

Doing so, frankly, is perverse.

We call this Unmetered Mitigation. It stems from a basic idea: you shouldn't have to pay more to be protected from bullies who try and silence you online. Regardless of what Cloudflare plan you use — Free, Pro, Business, or Enterprise — we will never tell you to go away or that you need to pay us more because of the size of an attack. Cloudflare's higher tier plans will continue to offer more sophisticated reporting, tools, and customer support to better tune our protections against whatever threats you face online. But volumetric DDoS mitigation is now officially unlimited and unmetered."

:-|

Cloudflare's new Rate-limiting. Beware

19 gopi_ar 9 years ago 10 comments

Reporting the freakiest phishing attack ever?

2 gopi_ar 9 years ago 0 comments

Comment · 10 years ago

This makes sense, we can rest easy knowing they didn't break out of the container. Thanks!

Comment · 10 years ago

Update: I sent an email to the email on that script. And the person at the other end replied and mentioned that he/she is doing it for extra pocket money and was only mining on the server. We aren't going to pursue any legal charges, might even pay the person a bounty for pointing out this vulnerability. I'd like to thank all of you, with special mention to some folks over at reddit for all your help!

Comment · 10 years ago

Here you go: https://kevinchen.co/blog/postmortem-server-compromised/

Comment · 10 years ago

We were able to get in touch with the hacker and he told us he was just mining and not stealing stuff. We're still cleaning the whole system; might even pay him/her a bounty for this though.

Comment · 10 years ago

Yes, it's a Redis vulnerability (caused by bad config on our part) in one container where the firewall was down.

Strange thing if we run 'top' from the main host, all containers running redis say 'statd' as their user; inside the container the user showed 'redis'. We removed nfs and all related files, and now it shows a user ID number. Is this something we should worry about?

Comment · 10 years ago

Thank you for responding.

We searched the whole system for authorized_keys files and found one created in a /var/lib/redis/ of a staging container (with no firewall) on this host. We then came across the redis vulnerability https://kevinchen.co/blog/postmortem-server-compromised/ . A junior dev had spawned this container without help from dev-ops and hence left ports open.

What doesn't make sense to us is how this daemon (yam) was running under a statd username when the container doesn't have such a user, but the host does? Are LXC containers able to run daemons on the host?