Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Github was hit by 1.35Tb DDoS attack establishing a new record - Page 2
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.

Github was hit by 1.35Tb DDoS attack establishing a new record

2»

Comments

  • AppleApple Member

    @WHT said:
    And why someone will ddos github?

    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)

    Thanked by 1netomx
  • ClouviderClouvider Member, Patron Provider

    Pity the GFW is not used to prevent from actual attacks.

  • SplitIceSplitIce Member, Host Rep
    edited March 2018

    @Neoon said:
    Wasn't the Mirai botnet 1.6Gbit?

    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.

  • qtwrkqtwrk Member

    @Clouvider said:
    Pity the GFW is not used to prevent from actual attacks.

    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

  • edited March 2018

    @Apple said:

    @WHT said:
    And why someone will ddos github?

    Sadly people attack anything these days, they do not need a reason.

    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.

  • jackbjackb Member, Host Rep
    edited March 2018

    @LosPollosHermanos said:

    @Apple said:

    @WHT said:
    And why someone will ddos github?

    Sadly people attack anything these days, they do not need a reason.

    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.

  • risharderisharde Patron Provider, Veteran

    Wow, that is some serious throughput figures! Thank goodness my memcache server was behind nat.

  • ZerpyZerpy Member

    @risharde said:
    Wow, that is some serious throughput figures! Thank goodness my memcache server was behind nat.

    Sane people do basic firewalls.. right?

  • RafayRafay Member

    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

  • Clouvider said: Pity the GFW is not used to prevent from actual attacks.

    Are you suggesting that there is a trade deficit with network packets.?

  • hzrhzr Member

    bsdguy said: Obviously both the memcached team and many (most?) users are utterly incompetent retards who ignored very basic rules, but one would be very mistaken to believe that that is an exception.

    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.

    Thanked by 3Aidan Sumeragi FHR
  • SplitIceSplitIce Member, Host Rep

    @hzr said:

    bsdguy said: Obviously both the memcached team and many (most?) users are utterly incompetent retards who ignored very basic rules, but one would be very mistaken to believe that that is an exception.

    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

    Thanked by 3pike Aidan FHR
  • edited March 2018

    @SplitIce said:

    @hzr said:

    bsdguy said: Obviously both the memcached team and many (most?) users are utterly incompetent retards who ignored very basic rules, but one would be very mistaken to believe that that is an exception.

    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.

  • bsdguybsdguy Member
    edited March 2018

    @hzr said:

    bsdguy said: Obviously both the memcached team and many (most?) users are utterly incompetent retards who ignored very basic rules, but one would be very mistaken to believe that that is an exception.

    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.

    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!

  • hzrhzr Member

    LosPollosHermanos said: CentOS v7 (and I presume v6 and v5) memcached binds to 0.0.0.0 by default. Luckily the fix is simple.

    >

    CentOS also firewalls all ports by default, doesn't it?

  • hzrhzr Member

    bsdguy said: one (1) single fucking TCP session setup packet exchange

    I like how QUIC handles this issue

  • eva2000eva2000 Veteran
    edited March 2018

    LosPollosHermanos said: CentOS v7 (and I presume v6 and v5) memcached binds to 0.0.0.0 by default. Luckily the fix is simple.

    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.

    Thanked by 1Aidan
  • @eva2000 said:
    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.

    Thanked by 2hostdare Aidan
  • edited March 2018

    @eva2000 said:

    LosPollosHermanos said: CentOS v7 (and I presume v6 and v5) memcached binds to 0.0.0.0 by default. Luckily the fix is simple.

    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.

    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.

  • hzrhzr Member

    imthatguyhere said: 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.

    It is in ubuntu and debian as far as I can tell

  • WSSWSS Member

    @hzr said:

    imthatguyhere said: 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.

    It is in ubuntu and debian as far as I can tell

    Can't forget mint!

  • hzrhzr Member

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

  • edited March 2018

    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

    PORT="11211"

    USER="memcached"

    MAXCONN="1024"

    CACHESIZE="64"

    OPTIONS="-l 127.0.0.1"

  • imthatguyhere said: but not in the repos of major Distros, which is part of the issue.

    Cheers.. will be interesting to see what the distros do for updates.

  • @LosPollosHermanos said:
    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.

    Correct, it's literally just a config that is set to 0.0.0.0 in RHEL / Centos Repos at least, if not more.

    @eva2000 said:
    Cheers.. will be interesting to see what the distros do for updates.

    Hopefully they don't expect users to be intelligent and edit configs before disabling firewall rules anymore, that would be a good start.

Sign In or Register to comment.