New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Sadly people attack anything these days, they do not need a reason.
Oles posted this list on his twitter. OVH was also hit by 1.3tb/s and it looks like most IPs/ASN are from China. (No surprise i also get hit by chinese ip addresses every day)
Pity the GFW is not used to prevent from actual attacks.
I don't believe Mirai broke 1Tbps. We saw around 300Gbps (from memory) when we got hit. By the end though it dropped as multiple targets were being hit by the same devices reducing the traffic hitting each target.
lol, it's probably gonna have white-list mode in stead of current black-list mode, I guess you wouldn't be bothered by hit by Chinese IP anymore by then
I've never understood the logic either. It seems to me like it's mostly just script kiddies who just get a kick out of it. Like it's a video game or something. Maybe for bragging rights.
It is common for criminals and script kiddies to prove their DDoS services by taking down high profile & well protected sites. Krebs' site was a very notable example in the past.
Wow, that is some serious throughput figures! Thank goodness my memcache server was behind nat.
Sane people do basic firewalls.. right?
OMG!
who whould like to compare OVH vs Github protection now?
OVH also get about 1.3TB DDOS attack so i think they both have pretty much great protection.
Back in the day my minecraft server withstood a 512mb UDP flood for 1 hour
Are you suggesting that there is a trade deficit with network packets.?
Effectively every single distro-shipped/packaged version binds to localhost only. The only incompetent retards involved here are people either running it in docker and intentionally forwarding 0.0.0.0:* instead of appropriately linking containers, or people compiling from scratch without reading the readme and without reading the multiple comments about it.
And people running popular pre-packaged software that includes an incorrectly configured Memcached e.g Zimbra
CentOS v7 (and I presume v6 and v5) memcached binds to 0.0.0.0 by default. Luckily the fix is simple.
I'm sure that RPM will be updated shortly.
I'd say that if something serves as the basis for one of the top-5 DDOS ever "but it's the users fault!" doesn't cut it anymore.
Well noted, I understand perfectly well that udp has its attractive sides but we all also know fucking well that udp by its very nature suffers from a spoofed source problem. That, plus the fact that something, in this cache memcached, can by design be used as a major amplifier/reflector would tell everyone with a brain to put some safety into his stuff. And no, "the default config is OK" is not some safety but a lame excuse.
You see, we have pretty much wire speed sym crypto and plenty of other funny devices available nowadays (well, actually since many years). Hell, even shitty open/libre/polar/snakeoil-ssl/tls are good enough for pretty high post-setup speeds (e.g. aes). Even better, I'm not even asking for encryption but merely for some kind of access control, say, one (1) single fucking TCP session setup packet exchange.
So no, there is no fucking excuse for memcached acting like an ignorant lobotomized retard!
>
CentOS also firewalls all ports by default, doesn't it?
I like how QUIC handles this issue
Don't think i ever seen that usually defaults to localhost or 127.0.0.1 and on centos 7 firewalld blocks UDP by default https://access.redhat.com/solutions/3369081 and https://bugzilla.redhat.com/show_bug.cgi?id=1551182
Not 100% sure though I always had source compiled memcached with 127.0.0.1 default and CSF Firewall enabled blocking the ports.
It's bound to all interfaces and turned off when installed. You enable the service and remove the firewall restrictions and it's open to the net. Memcached compiled by default is restricted to 127.0.0.1 for UDP, but not in the repos of major Distros, which is part of the issue.
As of today, CE7 memcached RPM (memcached-1.4.15-10.el7_3.1) binds to 0.0.0.0 by default. That means that the version included with CE6 and CE5 most likely do as well.
The fix is simple and they can easily change the default on the RPM. So they most likely will.
It is in ubuntu and debian as far as I can tell
Can't forget mint!
Those autostart on install, but bind local default
Centos binds global for some cases but requires manual configure and enable and firewall whitelisting of port
RHEL is basically same as centos
So...
It's not a compile configuration as far as I can tell. It's just a plain text config file that needs to be changed.
On Debian/Ubuntu I think it's /etc/memcached.conf.
On CentOS it's /etc/sysconfig/memcached
Cheers.. will be interesting to see what the distros do for updates.
Correct, it's literally just a config that is set to 0.0.0.0 in RHEL / Centos Repos at least, if not more.
Hopefully they don't expect users to be intelligent and edit configs before disabling firewall rules anymore, that would be a good start.