
KrebsOnSecurity is now up and hosted on Google Cloud - Usu
https://who.is/dns/krebsonsecurity.com
======
poooogles
I've always wondered how Google would deal with a client on GCP being DDoSed.
Mainly as were in online advertising and DDoS extortion isn't uncommon.

Guess with this I'll now find out, as crapping on Krebs' site is practically a
right of passage when you've got a botnet now.

~~~
hrrsn
I'd wager this is Project Shield rather than regular GCP.
[https://projectshield.withgoogle.com/public/](https://projectshield.withgoogle.com/public/)

~~~
pfg
There's a "server: shield" response header for krebsonsecurity.com, so this is
probably a good guess.

~~~
Springtime
Krebs confirmed this in his latest blog post [1].

 _Today, I am happy to report that the site is back up — this time under
Project Shield, a free program run by Google to help protect journalists from
online censorship._

[1] [https://krebsonsecurity.com/2016/09/the-democratization-
of-c...](https://krebsonsecurity.com/2016/09/the-democratization-of-
censorship/)

------
PuffinBlue
I've always wondered just how much a network run by someone like Google or
Facebook or one of the other absolute top tier providers like AWS or Azure
might be able to 'handle' in terms of dealing with DDoS attacks.

Presumably these giants can easily handle such traffic as long as someone is
willing to pay for the privilege? 665gbps seems tiny in comparison to the
capacity someone like Google might have at its disposal but I'm speculating as
I haven't seen anything detailing their network stats.

To give something of a concluding statement to this waffle I guess I have
respect for Google in running this public service type protection for sites
that have a strong enough 'public good' element.

~~~
williamstein
For what it is worth: My GCP-hosted site
([https://cloud.sagemath.com](https://cloud.sagemath.com)) was hit by a DDoS
attack in April (a WordPress amplification attack), which was about 5GB/s at
peak time. The GCP network had no problem handling the traffic, but the Linux
network stack in my cluster of GCE VMs -- which were running nginx -- simply
couldn't handle the load. I now use CloudFlare.

~~~
boulos
Sorry for your troubles! Why'd you let it through, Bill? (Also, did Support
help you out with this or not? You can email me your case number if so).

Disclosure: I work on Google Cloud.

------
mtgx
If the 665 Gbps botnet was indeed powered by mainly IoT devices, then this is
only the very beginning. We're about to see multi-Tbps botnets soon, all
because most IoT companies could care less about security, and because most of
them want to connect every IoT device to the Internet _by default_ (rather
than through a gateway, which at least could limit infections).

~~~
mschuster91
> and because most of them want to connect every IoT device to the Internet by
> default

Stuff is going to get even worse when IoT devices begin using IPv6. By design,
devices are publically reachable and not hidden behind a NAT router, which
makes RCE exploits way, way easier.

I'd take a guess that loads of IoT devices have "backdoors" like open
SSH/telnet with insecure default passwords, too - the same shit that hit el-
cheapo routers, for example.

~~~
therealidiot
Let's hope router manufacturers include sensible firewall defaults. They
probably won't in many cases, though.

~~~
mschuster91
They can't, because IoT.

IoT devices like surveillance cams, VoIP babyphones etc. have two options:

1) depend on third-party servers for operation, so no outside-to-device-
initiated communication is needed. Downside: costs money to run the servers,
and just imagine the sausagefest when a camera cloud server gets hacked.
Upside: you can firewall off your private network as you like, and the device
will still work.

2) allow the owner of the device to directly connect to the IoT device via
IPv6. Downside: everyone and their dog can access (and exploit) your devices,
provided that they know the IP address. IPv6 addresses are long and pretty
random, but e.g. if the MAC address is used for assigning the IPv6 address,
not so random any more. Upside: no SPOF/centralized node that turns your
device into a brick if the operator shuts down.

Basically, the only way to "securely" operate IoT devices is inside a separate
VLAN. FritzBox routers can do this, but not many others, e.g. because the
router can't independently manage the Ethernet ports, because it's cheaper to
put in a GBit switch than to choose a SoC that's beefy enough to drive four
GBit ports individually. I put "securely" into quotation marks, as a hacked
surveillance cam or babyphone is an open invitation to any hacker.

~~~
mercora
i would say making secure tunnels a default for home routers would be a better
mitigation... there is no need to control my "smart home" or what ever from my
neighbors phone...

Some things just do not make much sense without being able to control them
remotely. A separate VLAN for devices would only allow them to communicate
with another which probably is not what you want. BTW. i could not set up
VLANs on a fritz box with FritzOS last time i tried. However nearly all
routers with OpenWRT will do without a problem.

~~~
kalleboo
The only way to get it well-adopted would be if you could get Google, Apple,
Microsoft and router manufacturers to agree on some user-friendly and secure
way to set up tunnels and connect to them from your phone/devices. Good luck
with that...

~~~
mercora
While a common agreement on how this should be done would be the best
solution, it should be enough to have at least some option to setup such
tunnels through an API. Router manufactures could develop an App to make that
setup easier then.

Although this wont be practical for any device that is not a phone or a
(desktop) computer.

~~~
ge0rg
And then there would be malware running in your browser that uses the API to
expose your IoT devices. There is precedent for that where Javascript in the
browser was accessing your router's web interface (with default credentials)
to change your DNS server.

~~~
fragmede
That's just another target among many in the broader class of XSS attacks, and
there are protections that router manufacturers (and anyone else hosting a
website) are able to build in to protect against it.

Unfortunately, this belies the meat of the issue with IoT. After you've bought
the router, there's no reason for your router's manufacturer to keep updating
the firmware and fix bugs that allow an XSS attack, and even if the
manufacturer does upgrade the firmware, there's no no way for the manufacture
to force the firmware to be updated on _all_ of the devices that have been
sold, hence installed devices with older firmware that's been exploited and is
now part of the botnet used to attack Krebsonsecurity.com

------
alpb
Can somebody please enlighten me, why is this vague post on the front page
with no comments and 8 upvotes?

~~~
BozeWolf
The original post [1] about krebsonsecurity being kicked of akamai (for valid
reasons) had a lot (480) of reactions. I think a many of readers of that post
see this as a valuable follow-up.

[1]
[https://news.ycombinator.com/item?id=12561928](https://news.ycombinator.com/item?id=12561928)

------
tim333
>KrebsOnSecurity is now up...

It isn't for me. I get "This site can’t be reached - krebsonsecurity.com
refused to connect."

~~~
notimetorelax
Looks like redirect from naked domain to www.krebsonsecurity.com is missing.
This seem to work better
[http://www.krebsonsecurity.com/](http://www.krebsonsecurity.com/)

~~~
semi-extrinsic
Clicking your link doesn't work either for me (connection refused).

~~~
pfg
DNS might still be propagating. krebsonsecurity.com pointed to 127.0.0.1 while
the site was offline.

~~~
darfs
Works fine in Germany also.

------
tux1968
Now that he has quickly found another safe harbor, this attack may well have a
sort of Streisand effect and give Brian Krebs more prominence than he already
had. Would be nice to see something good come out of this and maybe even cause
future attacks to be seen as counterproductive by potential perpetrators.

------
user5994461
The solution I'd like to see:

1) Put the site behind CloudFlare.

2) Wait for an attack...

3) Force all users to go through a capcha before accessing the site.

Note: The capcha setting can be enabled with 3 clicks in cloudflare UI and it
takes 2-5 minutes to propagate. (Yes, I speak from experience)

~~~
michaelt
Krebs won't use Cloudflare because Cloudflare protect DDOS-for-hire sites from
each other. He thinks, before CF offered this protection, the DDOS-for-hire
services would take one another offline; and that it's an ethical problem, for
CF to be protecting the very people whose criminal acts create (some of) the
demand for their services.

Cloudflare, in their defence, say they don't censor/check/approve sites and
that's a good thing - after all, sites like wikileaks should be allowed
protection.

~~~
bitmapbrother
I'm all for free speech, but protecting sites that commit criminal activities
is not a "good thing". In fact, they should be partly liable for the damage if
they were aware of it and did nothing to stop it.

------
mxpxrocks10
seems to be down again at 6:06AM PST

sometimes you can get the HTML to load from :80 but the CSS breaks. HTTPS
doesn't seem to work at all.

------
imaginenore
How would that solve anything? He would have to pay crazy Google CDN fees now:

[https://cloud.google.com/cdn/pricing](https://cloud.google.com/cdn/pricing)

At 650 Gbps (81.25 GB/s) he's looking at $1.625/sec ($5850/hr) in cache egress
fees alone.

I would go CloudFlare, which is flat rate.

~~~
phihag_
He's not using Google CDN, but Google Project Shield:
[https://projectshield.withgoogle.com/public/](https://projectshield.withgoogle.com/public/)
. Project Shield is a free service.

------
mkopinsky
Unfortunately I can't get to the new site (without changing my DNS servers)
because Verizon is resolving krebsonsecurity.com to loopback. Presumably doing
it for (poor) DDOS mitigation, but this sort of censorship is ridiculous.

    
    
        $ nslookup krebsonsecurity.com 71.242.0.12
        Server:   71.242.0.12
        Address:  71.242.0.12#53
        
        Non-authoritative answer:
        Name: krebsonsecurity.com
        Address: 127.0.0.1
    

EDIT: I see downthread that this is a DNS propagation issue. Nevermind.

~~~
gipsies
A wild claim without any source. The owner set the IP to localhost himself.

[https://twitter.com/briankrebs/status/779144394360381440](https://twitter.com/briankrebs/status/779144394360381440)

~~~
mkopinsky
While in this case I was wrong, DNS poisoning is certainly not out of the
realm of what Verizon will do, and when a site resolves properly on one ISP
and not another, I don't think it's a "wild claim" to assume that it's the
ISP's fault.

