Re: Cloudflare contact?

[Justin Paine via NANOG]

Replying directly.

On Sun, Feb 19, 2023 at 5:31 PM John Von Essen  wrote:

> I work with DuckDuckGo, and earlier today our macOS browser (which is
> currently available via the App store now) started getting caught by
> Cloudflare’s bot/fraud system. We did a fair amount of debugging, it
> appears to be some kind of browser/UA fingerprinting. This is happening for
> pretty much anyone using our browser, anywhere in the world, when browsing
> cloudflare powered sites. My hunch is this is accidental, but since we have
> no direct contacts at Cloudflare, we’re having a hard time escalating this.
>
> Thanks
> John

-- 



__
*Justin Paine*
He/Him/His
VP, Global Head of Trust & Safety
101 Townsend St, San Francisco, CA 94107 

*PGP:* BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D

Re: Any CloudFlare Rep?

[Justin Paine via NANOG]

Hi,

Replying off list.



__
*Justin Paine*
He/Him/His
Threat Intel
101 Townsend St, San Francisco, CA 94107 

*PGP:* BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D



On Mon, Jul 19, 2021 at 8:39 AM Kushal R. via NANOG  wrote:

> Could someone from CloudFlare please contact me off the list? There is
> some crazy abuse going on one a site proxied through CF. Tried the usual
> twitter and abuse form. In the last 4 hours 2 people I know personally have
> lost $500+ each and hundreds are falling prey each day.
>
>
> —
> Kushal R.
> *Executive Management*
> 
> WhatsApp: +1-(954)-737-4335 <+19547374335>
> Skype: kush.raha
>
> Host4Geeks LLC - Premium Managed Hosting 
> Trusted by over 10,000 Clients Globally
>
> 
> 
>

Re: Something that should put a smile on everybody's face today

[Justin Paine via NANOG]

Correction -- another one.
https://blog.cloudflare.com/winning-the-blackbird-battle/   :)

Here's an except from the new blog post:

offering $100,000 to be shared by the winners who are successful in finding
such prior art.

Please help!



__
*Justin Paine*
He/Him/His
Head of Trust & Safety
101 Townsend St, San Francisco, CA 94107 

*PGP:* BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D



On Tue, Apr 27, 2021 at 3:26 PM Michael Thomas  wrote:

>
> And we can help! Cloudflare is setting out to destroy a patent troll:
>
>
> https://www.techdirt.com/articles/20210426/09454946684/patent-troll-sable-networks-apparently-needs-to-learn-lesson-cloudflare-wants-to-destroy-another-troll
>
> Mike
>
>

Re: login.authorize.net has A and CNAME records

[Justin Paine via NANOG]

For the thread -- we're aware and looking into this.  n...@cloudflare.com
being the best place to report these kinds of things.



__
*Justin Paine*
He/Him/His
Head of Trust & Safety
101 Townsend St, San Francisco, CA 94107 

*PGP:* BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D



On Tue, Apr 6, 2021 at 2:49 PM Mark Andrews  wrote:

>
>
> > On 7 Apr 2021, at 05:59, Arne Jensen  wrote:
> >
> >
> > Den 06-04-2021 kl. 21:47 skrev Seth Mattinen:
> >>
> >>>
> >>> What kind of local problem or network problems could cause a servfail
> >>> response from the authoritative ns?
> >>
> >>
> >>
> >> I'm beginning to think this is a DNSSEC related problem, I'll ask on
> >> the pdns-users list. I see it's asking for a DS record on
> >> login.authorize.net.cdn.cloudflare.net when the nearest one appears to
> >> be at cloudflare.net, so for some reason that's not being applied all
> >> the way down.
> >
> > I do somehow take that "local problem" part back again, which also
> > wasn't intended exactly in the way that it was written:
> >
> > ->
> >
> https://dnssec-analyzer.verisignlabs.com/login.authorize.net.cdn.cloudflare.net
> >
> > Is looking at login.authorize.net.cdn.cloudflare.net/DNSKEY, but failing
> > due to the SERVFAIL.
> >
> > -> https://dnsviz.net/d/login.authorize.net.cdn.cloudflare.net/dnssec/
> >
> > Seems to claim that it works just fine.
> >
> > Asking login.authorize.net.cdn.cloudflare.net/DNSKEY or
> > login.authorize.net.cdn.cloudflare.net/DS returns SERVFAIL here too.
> >
> >
> > But I don't think you should be querying /DNSKEY or /DS, except a the
> > (current) delegation's root, e.g. as you say yourself, at
> > "cloudflare.net" in this case.
>
> It shouldn’t matter if you query for them.  If the records don’t exist then
> you should get back NOERROR/NODATA responses with NSEC/NSEC3 records to
> prove
> those responses.
>
> Note the server claims that TXT records exist at
> login.authorize.net.cdn.cloudflare.net
> but can’t return them.
>
>
> % dig login.authorize.net.cdn.cloudflare.net type65 @198.41.222.31 +dnssec
>
> ; <<>> DiG 9.15.4 <<>> login.authorize.net.cdn.cloudflare.net type65 @
> 198.41.222.31 +dnssec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1641
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1232
> ;; QUESTION SECTION:
> ;login.authorize.net.cdn.cloudflare.net.IN TYPE65
>
> ;; AUTHORITY SECTION:
> cloudflare.net. 5   IN  SOA ns1.cloudflare.net.
> dns.cloudflare.com. 1617743605 1 2400 604800 5
> login.authorize.net.cdn.cloudflare.net. 5 IN NSEC \
> 000.login.authorize.net.cdn.cloudflare.net. A HINFO MX TXT  LOC SRV
> NAPTR CERT SSHFP RRSIG NSEC TLSA SMIMEA HIP OPENPGPKEY TYPE64 SPF URI CAA
> cloudflare.net. 5   IN  RRSIG   SOA 13 2 5 20210407221325
> 20210405201325 34505 cloudflare.net.
> BfBNcB9zG3T6d7mu5okde144g0OlxBazynPBD78o/ig5y0JHWo+L2ufu
> mhSfOquAkq6lqa/V+3yySMERlQKcIQ==
> login.authorize.net.cdn.cloudflare.net. 5 IN RRSIG NSEC 13 6 5
> 20210407221325 20210405201325 34505 cloudflare.net.
> +shgKZcdkQZvH9ZFEZvdXyHe7+FkX1mCit9xe4V7A+uEEYi3L7vnf16x
> Wyvzs0o4TlQiOJlYBG4vEkKE3d8NwQ==
>
> ;; Query time: 17 msec
> ;; SERVER: 198.41.222.31#53(198.41.222.31)
> ;; WHEN: Wed Apr 07 07:13:25 AEST 2021
> ;; MSG SIZE  rcvd: 417
>
> %
>
> % dig login.authorize.net.cdn.cloudflare.net txt @198.41.222.31 +dnssec
>
> ; <<>> DiG 9.15.4 <<>> login.authorize.net.cdn.cloudflare.net txt @
> 198.41.222.31 +dnssec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46557
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1232
> ;; QUESTION SECTION:
> ;login.authorize.net.cdn.cloudflare.net.IN TXT
>
> ;; Query time: 15 msec
> ;; SERVER: 198.41.222.31#53(198.41.222.31)
> ;; WHEN: Wed Apr 07 07:14:22 AEST 2021
> ;; MSG SIZE  rcvd: 67
>
> %
>
> > Or if "cdn.cloudflare.net" had been a sub-delegation, then at that
> point...
> >
> > --
> > Med venlig hilsen / Kind regards,
> > Arne Jensen
> >
> >
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
>

Re: Florida: Voter registration website overwhelmed at deadline

[Justin Paine via NANOG]

no indication of a DoS attack.



__
*Justin Paine*
He/Him/His
Head of Trust & Safety
101 Townsend St, San Francisco, CA 94107 

*PGP:* BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D



On Tue, Oct 6, 2020 at 9:51 AM Sean Donelan  wrote:

>
> Every election has problems. Most of the time, those problems aren't
> noticed. Elections rely on a lot of back-end infrastructure, besides the
> actual voting itself.
>
> It could be a DDOS attack, or simply duct-taped systems having trouble
> with the load.
>
> Voting early (mail, drop-off, in-person) means more time to fix glitches.
>
>
>
>
> https://apnews.com/article/virus-outbreak-election-2020-florida-elections-ron-desantis-dc8aaf2213b6c50451019a7c0c07c3f7
>
> The FBI and the Cybersecurity and Infrastructure Security Agency warned
> elections officials nationwide last week that cyberattacks could disrupt
> their systems during the run-up to the election. They particularly noted
> “distributed denial-of-service” attacks, which inundate a computer system
> with requests, potentially clogging up servers until the system becomes
> inaccessible to legitimate users.
>

Re: cloudflare 1.1.1.2 filtered DNS

[Justin Paine via NANOG]

Hi Bill,

Report it via the form you mentioned and the team will review it shortly.
We don't currently publish our data sources for the filtered service.

Thanks,
Justin



_
*Justin Paine*
He/Him/His
Head of Trust & Safety
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D

101 Townsend St, San Francisco, CA 94107



On Tue, Aug 11, 2020 at 3:25 PM William Herrin  wrote:

> Howdy,
>
> Is there an RBL lookup that provides information on why Cloudflare has
> elected to block a name lookup via the "1.1.1.1 for Families" service
> or is it a black box where you can only complain via
> https://report.teams.cloudflare.com/ and maybe they'll do something
> about it?
>
> Thanks,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: CloudFlare Issues?

[Justin Paine via NANOG]

The team is working on it.

_
*Justin Paine*
Head of Trust & Safety
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D

101 Townsend St., San Francisco, CA 94107



On Fri, Jul 17, 2020 at 2:53 PM  wrote:

> Chris Grundemann wrote on 7/17/2020 2:38 PM:
>
> Looks like there may be something big up (read: down) at CloudFlare, but
> their status page is not reporting anything yet.
>
> Am I crazy? Or just time to give up on the internet for this week?
>
> --
> @ChrisGrundemann
> http://chrisgrundemann.com
>
> Status page just updated: Edge network and resolver issues.
>
> We had noticed something was up on our network as well w/ IPv6 name
> resolution timing out for some sites.
>
>
>

Re: Cloudflare Contacts

[Justin Paine via NANOG]

Hi,

I forwarded this internally -- trying to locate the right contact for you.

_
*Justin Paine*
Head of Trust & Safety
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D
101 Townsend St., San Francisco, CA 94107



On Tue, Mar 31, 2020 at 8:13 PM John Von Essen  wrote:

> Could someone from Cloudflare contact me off-list?
>
> I work for a major search engine (not google or bing), and we just
> launched some assets in Brazil, seeing some weird behavior to Cloudflare
> CDN assets and thinking maybe we are being caught in some kind of
> filter/block.
>
> Our image search traffic is proxied through a single IP, so its definitely
> high volume. We’ve never had an issue in other regions, but it could due to
> the sudden increase.
>
> Thanks
> John Von Essen

Re: Honeypot type services from cloud flare or other security groups?

[Justin Paine via NANOG]

Hi Brielle,

Happy to chat directly — drop me a direct email please? 

Thanks,

Justin

_
*Justin Paine*
Head of Trust & Safety
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D
101 Townsend St., San Francisco, CA 94107

On Wed, Mar 11, 2020 at 8:28 AM, Brielle < br...@2mbit.com > wrote:

> 
> 
> 
> Hi all,
> 
> 
> 
> Sorry for formatting errors, on my iPad while I have this thought in my
> mind.
> 
> 
> 
> Does anyone know if any of the security groups or CDNs like Cloudflare
> have honeypots out there that can be used for analysis of unusual attacks?
> As in, change the DNS temp for a host and let the honey pot take the brunt
> of it and hopefully get useful data (even for the benefit of the security
> company).
> 
> 
> 
> Got a situation where I’ve got an abnormally high amount of legit looking
> GET requests to a HTTPS git server, but are too high amount to actually be
> legit end users or people cloning the repos. The sources are worldwide,
> distributed, but with the bulk coming from China, Russia, Brazil, and
> Egypt.
> 
> 
> 
> I have some theories and observations that I’d be open to sharing, but
> preferably not on an open mailing list until I’ve had a change to have
> them reviewed by someone with more experience and background.
> 
> 
> 
> Thx!
> 
> 
> 
> Sent from my iPad
> 
> 
>

Re: CloudFlare issues?

[Justin Paine via NANOG]

FYI for the group -- we just published this:
https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/


_
*Justin Paine*
Director of Trust & Safety
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D
101 Townsend St., San Francisco, CA 94107



On Mon, Jun 24, 2019 at 2:25 PM Mark Tinka  wrote:

>
>
> On 24/Jun/19 18:09, Pavel Lunin wrote:
>
> >
> > Hehe, I haven't seen this text before. Can't agree more.
> >
> > Get your tie back on Job, nobody listened again.
> >
> > More seriously, I see no difference between prefix hijacking and the
> > so called bgp optimisation based on completely fake announces on
> > behalf of other people.
> >
> > If ever your upstream or any other party who your company pays money
> > to does this dirty thing, now it's just the right moment to go explain
> > them that you consider this dangerous for your business and are
> > looking for better partners among those who know how to run internet
> > without breaking it.
>
> We struggled with a number of networks using these over eBGP sessions
> they had with networks that shared their routing data with BGPmon. It
> sent off all sorts of alarms, and troubleshooting it was hard when a
> network thinks you are de-aggregating massively, and yet you know you
> aren't.
>
> Each case took nearly 3 weeks to figure out.
>
> BGP optimizers are the bane of my existence.
>
> Mark.
>
>

Re: Any Fastly CDN engineers here?

[Justin Paine via NANOG]

Replying offlist.


Justin Paine
Head of Trust & Safety
Cloudflare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D

On Wed, Jun 20, 2018 at 4:59 PM Hank Disuko  wrote:
>
> Bit of a longshot, but I'm having some very interesting issues with the 
> Fastly nodes in Miami.
>
>
> Thanks,
>
> Hank.

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Justin Paine via NANOG]

Thanks Chip!


Justin Paine
Head of Trust & Safety
Cloudflare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Tue, Feb 27, 2018 at 1:52 PM, Chip Marshall  wrote:
> On 2018-02-27, Ca By  sent:
>> Please do take a look at the cloudflare blog specifically as they name and
>> shame OVH and Digital Ocean for being the primary sources of mega crap
>> traffic
>>
>> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
>>
>> Also, policer all UDP all the time... UDP is unsafe at any speed.
>
> Hi, DigitalOcean here. We've taken steps to mitigate this attack on our 
> network.
>
> Also, we've only seen udp/11211 being a problem. I'd be interested to
> hear of anyone seeing tcp/11211 attacks.
>
> --
> Chip Marshall 
> http://2bithacker.net/

Re: loc.gov

[Justin Paine via NANOG]

Both loading in SF over Comcast without  issue  


_
Justin Paine
Head of Trust & Safety
Cloudflare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D






On Sat, Jul 8, 2017 at 1:49 PM -0700, "Joly MacFie"  wrote:










I see http://congress.gov/ is out too.



On Sat, Jul 8, 2017 at 4:43 PM, Joly MacFie  wrote:

> (sorry I'm not on the outage list)
>
> Any clues as to what the problem is at the Library of Congress? Appears to
> be DNS. Is it a DDOS?
>
> http://www.loc.gov/
>
>
>
> --
> ---
> Joly MacFie  218 565 9365 <(218)%20565-9365> Skype:punkcast
> --
> -
>



-- 
---
Joly MacFie  218 565 9365 Skype:punkcast
--
-

Re: PSN (Playstation Network) security team

[Justin Paine via NANOG]

Sounds like you already received a reply.


Justin Paine
Head of Trust & Safety
Cloudflare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Fri, Apr 28, 2017 at 8:44 AM, Aaron Gould  wrote:
> That's a good word Andrew
>
> -Aaron
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Andrew Kirch
> Sent: Thursday, April 27, 2017 11:47 PM
> To: John A. Kilpatrick 
> Cc: NANOG list 
> Subject: Re: PSN (Playstation Network) security team
>
> Arrogance almost always proceeds humiliation.
>
> Andrew
>
> On Fri, Apr 28, 2017 at 12:39 AM, John A. Kilpatrick 
> wrote:
>
>> Which is kinda funny when you think about it.
>>
>> --
>>John A. Kilpatrick
>> j...@hypergeek.netEmail| http://www.hypergeek.net/
>> john-p...@hypergeek.net  Text pages|  ICQ: 19147504
>>  remember:  no obstacles/only challenges
>>
>> > On Apr 27, 2017, at 1:51 PM, Tony Wicks  wrote:
>> >
>> > snei-noc-ab...@am.sony dot com
>> >
>> > Good luck with that! Sony is uniquely difficult to deal with when it
>> comes to the arrogance of their "security" people at PSN.
>> >
>> >
>> >
>> > -Original Message-
>> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Josh
>> > Luthman
>> > Sent: Friday, 28 April 2017 7:27 AM
>> > To: NANOG list 
>> > Subject: PSN (Playstation Network) security team
>> >
>> > I'm hoping someone here can reach out to me from the department that
>> deals with automatically blocking IPs.  As far as I can tell they're
>> all in the same /24.  The phone support is completely worthless in
>> this situation (I'm supposed to change my ISP).
>> >
>> > Josh Luthman
>> > Office: 937-552-2340
>> > Direct: 937-552-2343
>> > 1100 Wayne St
>> > Suite 1337
>> > Troy, OH 45373
>> >
>>
>

Re: Recent NTP pool traffic increase

[Justin Paine via NANOG]

replying off list.


Justin Paine
Head of Trust & Safety
Cloudflare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Mon, Dec 19, 2016 at 1:49 PM, Dan Drown  wrote:
> Quoting David :
>>
>> On 2016-12-19 1:55 PM, Jan Tore Morken wrote:
>>>
>>> On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote:

 I found devices doing lookups for all of these at the same time

 {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa}.pool.ntp.org
 and then it proceeds to use everything returned, which explains why
 everyone is seeing an increase.
>>>
>>>
>>> Thanks, David. That perfectly matches the list of servers used by
>>> older versions of the ios-ntp library[1][2], which would point toward
>>> some iPhone app being the source of the traffic.
>>>
>>> [1]
>>> https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts
>>> [2]
>>> https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9dec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122
>>>
>>
>> That would make sense - I see a lot of iCloud related lookups from these
>> hosts as well.
>>
>> Also, app.snapchat.com generally seems to follow just after the NTP pool
>> DNS lookups. I don't have an iPhone to test that though.
>
>
> Confirmed - starting up the iOS Snapchat app does a lookup to the domains
> you listed, and then sends NTP to every unique IP.  Around 35-60 different
> IPs.
>
> Anyone have a contact at Snapchat?

Re: Recent NTP pool traffic increase

[Justin Paine via NANOG]

the new Mario app perhaps? :)


Justin Paine
Head of Trust & Safety
Cloudflare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Mon, Dec 19, 2016 at 1:12 PM, David  wrote:
> On 2016-12-19 1:55 PM, Jan Tore Morken wrote:
>>
>> On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote:
>>>
>>> I found devices doing lookups for all of these at the same time
>>>
>>> {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa,europe}.pool.ntp.org
>>> and then it proceeds to use everything returned, which explains why
>>> everyone is seeing an increase.
>>
>>
>> Thanks, David. That perfectly matches the list of servers used by
>> older versions of the ios-ntp library[1][2], which would point toward
>> some iPhone app being the source of the traffic.
>>
>> [1]
>> https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts
>> [2]
>> https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9dec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122
>>
>
> That would make sense - I see a lot of iCloud related lookups from these
> hosts as well.
>
> Also, app.snapchat.com generally seems to follow just after the NTP pool DNS
> lookups. I don't have an iPhone to test that though.
>
> Thanks,
>

Re: Avalanche botnet takedown

[Justin Paine via NANOG]

straight from the horse's mouth -- they said  "99.99% of the 900,000
domains" have been sinkholed.


Justin Paine
Head of Trust & Safety
Cloudflare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Thu, Dec 1, 2016 at 1:02 PM, J. Hellenthal  wrote:
> 99% ? That's a pretty high figure there.
>
> --
>  Onward!,
>  Jason Hellenthal,
>  Systems & Network Admin,
>  Mobile: 0x9CA0BD58,
>  JJH48-ARIN
>
> On Dec 1, 2016, at 14:56, Rich Kulawiec  wrote:
>
>> On Thu, Dec 01, 2016 at 05:34:26PM -, John Levine wrote:
>> [...] 800,000 domain names used to control it.
>
> 1. Which is why abusers are registrars' best customers and why
> (some) registrars work so very hard to support and shield them.
>
> 2. As an aside, I've been doing a little research project for a
> few years, focused on domains.  I've become convinced that *at least*
> 99% of domains belong to abusers: spammers, phishers, typosquatters,
> malware distributors, domaineers, combinations of these, etc.
>
> In the last year, I've begun thinking that 99% is a serious underestimate.
> (And it most certainly is in some of the new gTLDs.)
>
> ---rsk
>

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Justin Paine via NANOG]

DNS Results for query A krebsonsecurity.comAnswer:krebsonsecurity.com 157 IN A 
130.211.45.45

On Google now. 

 
Justin Paine 
Head of Trust & Safety 
CloudFlare Inc. 
PGP: BBAA 6BCE 3305 7FD6 6452 711557B6 0114 DE0B 314D




On Sat, Sep 24, 2016 at 2:17 PM -0700, "Brett Watson"  
wrote:











>> 
> that's not the one I was thinking of, this is:
>  
> 
> which references your presentation, nice! and is about J-root, not K-root,
> but mentions Lorenzo's work on K-root studies... In anycase, both seem to
> say that 'tcp anycast works fine' (inside some set of parameters).
> 

Right… and we’ve known this since about… ? 1996?

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Justin Paine via NANOG]

We routinely mitigate L7s. Matthew is also on the record saying we've
seen and mitigated similar attacks to this one (based on available
information about this attack).


Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Fri, Sep 23, 2016 at 12:26 PM, Patrick W. Gilmore  wrote:
> Is CloudFlare able to filter Layer 7 these days? I was under the impression 
> CloudFlare was not able to do that.
>
> There have been a lot of rumors about this attack. Some say reflection, 
> others say Layer 7, others say .. other stuff. If it is Layer 7, how are you 
> going to ‘step in front of the cannon’? Would you just pass through all the 
> traffic?
>
> I realize Matthew is always happy for publicity (hell, the whole planet is 
> aware of that). But if your system cannot actually do the required task, I’m 
> not sure your company should give you credit for offering a service the user 
> cannot use.
>
> --
> TTFN,
> patrick
>
>> On Sep 23, 2016, at 3:16 PM, Justin Paine via NANOG  wrote:
>>
>> FWIW, we have offered to help. No word so far. We're more than willing
>> to step in front of the cannon pointed his way.
>>
>> 
>> Justin Paine
>> Head of Trust & Safety
>> CloudFlare Inc.
>> PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D
>>
>>
>> On Fri, Sep 23, 2016 at 11:58 AM, Marcin Cieslak  wrote:
>>> On Fri, 23 Sep 2016, jim deleskie wrote:
>>>
>>>> They were hosting him for free, and like insurance, I can assure you if you
>>>> are consistently using a service, and not covering the costs of that
>>>> service you won't be a client for long.  This is the basis for AUP/client
>>>> contracts and have been going back to the days when we all offered only
>>>> dialup internet.
>>>
>>> Does being a victim of a DDoS constitute a breach of AUP?
>>>
>>> Marcin Cieślak
>

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Justin Paine via NANOG]

FWIW, we have offered to help. No word so far. We're more than willing
to step in front of the cannon pointed his way.


Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Fri, Sep 23, 2016 at 11:58 AM, Marcin Cieslak  wrote:
> On Fri, 23 Sep 2016, jim deleskie wrote:
>
>> They were hosting him for free, and like insurance, I can assure you if you
>> are consistently using a service, and not covering the costs of that
>> service you won't be a client for long.  This is the basis for AUP/client
>> contracts and have been going back to the days when we all offered only
>> dialup internet.
>
> Does being a victim of a DDoS constitute a breach of AUP?
>
> Marcin Cieślak

Re: Domain renawals

[Justin Paine via NANOG]

I've had quite good luck with:  Gandi, Hover, 101domains, and Google
Domains -- depending on which cc/TLDs you're looking for.


Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Wed, Sep 21, 2016 at 6:35 PM, John Levine  wrote:
>>For domain registration I found that joining the GoDaddy Domain Club
>>( $120/year or less if you pay ahead for multiple years [1] ) ...
>
> There's a lot of registrars with prepay discounts.  Gandi's domains
> are cheaper if you prepay $600, a lot cheaper if you prepay $2000.
>
> R's,
> John

Re: "Defensive" BGP hijacking?

[Justin Paine via NANOG]

earlier on Twitter Krebs said he was hit by 665Gbps attack (so says
Prolexic/Akamai). Could be ongoing/related.


Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Tue, Sep 20, 2016 at 8:21 PM, Mel Beckman  wrote:
> While I was reading the krebsonsecurity.com article cited below, the site, 
> hosted at Akamai address 72.52.7.144, became non responsive and now appears 
> to be offline. Traceroutes stop before the Akamai-SWIPed border within Telia, 
> as if blackholed (but adjacent IPs pass through to Akamai):
>
> traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte packets
>  1  router1.sb.becknet.com (206.83.0.1)  0.771 ms  0.580 ms  0.342 ms
>  2  206-190-77-9.static.twtelecom.net (206.190.77.9)  0.715 ms  1.026 ms  
> 0.744 ms
>  3  ae1-90g.ar7.lax1.gblx.net (67.17.75.18)  9.532 ms  6.567 ms  2.912 ms
>  4  ae10.edge1.losangeles9.level3.net (4.68.111.21)  2.919 ms  2.925 ms  
> 2.904 ms
>  5  telia-level3-4x10g.losangeles.level3.net (4.68.70.130)  3.981 ms  3.567 
> ms  3.401 ms
>  6  sjo-b21-link.telia.net (62.115.116.40)  11.209 ms  11.140 ms  11.161 ms
>  7  * * *
>  8  * * *
>  9  * * *
> 10  * * *
>
> Weird coincidence?
>
>  -mel beckman
>
>> On Sep 20, 2016, at 6:46 PM, Hugo Slabbert  wrote:
>>
>> Lucy, you got some (*serious*) 'splainin to do...
>>
>> http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/
>> http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-has-history-of-hijacks/
>>
>> --
>> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
>> pgp key: B178313E   | also on Signal
>>
>>> On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher  wrote:
>>>
>>> So after reading your explanation of things...
>>>
>>> Your technical protections for your client proved sufficient to handle the
>>> attack. You took OFFENSIVE action by hijacking the IP space. By your own
>>> statements, it was only in response to threats against your company. You
>>> were no longer providing DDoS protection to a client. You were exacting a
>>> vendetta against someone who was being MEAN to you. Even if that person
>>> probably deserved it, you still cannot do what was done.
>>>
>>> I appreciate the desire to want to protect friends and family from
>>> anonymous threats, and also realize how ill equipped law enforcement
>>> usually is while something like this is occurring.
>>>
>>> However, in my view, by taking the action you did, you have shown your
>>> company isn't ready to be operating in the security space. Being threatened
>>> by bad actors is a nominal part of doing business in the security space.
>>> Unfortunately you didn't handle it well, and I think that will stick to you
>>> for a long time.
>>>
>>> On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend 
>>> wrote:
>>>
 @ca & Matt - No, we do not plan to ever intentionally perform a
 non-authorized BGP hijack in the future.

 @Steve - Correct, the attack had already been mitigated. The decision to
 hijack the attackers IP space was to deal with their threats, which if
 carried through could have potentially lead to physical harm. Although the
 hijack gave us a unique insight into the attackers services, it was not a
 factor that influenced my decision.

 @Blake & Mel - We will likely cover some of these questions in a future
 blog post.

Re: DNS Services for a registrar

[Justin Paine via NANOG]

Right -- we could do it, though it would be a first for us.



Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D

On Fri, Aug 12, 2016 at 1:17 PM, Filip Hruska  wrote:

> Even for registrars?
>
> Because OP's question was
> > We need to provide DNS services for domains we offer as a registrar.
>
> Best Regards,
> Filip
>
>
> On 12.8.2016 22:11, Justin Paine via NANOG wrote:
>
>> I won't push further than this -- but it seems a bit silly not to
>> mention that CloudFlare provides free AnyCast DNS. You can elect not
>> to even use any of our caching if you just want to use us for DNS.
>>
>> J
>>
>> 
>> Justin Paine
>> Head of Trust & Safety
>> CloudFlare Inc.
>> PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D
>>
>>
>> On Fri, Aug 12, 2016 at 12:24 PM, Peter Beckman 
>> wrote:
>>
>>> If there are other metrics in which to measure DNS speed, availability
>>> and
>>> redundancy, I'd love to seeing them. I have but my own datapoint and the
>>> metrics from others. Tear down the testing model, but at least show a
>>> different/better one in return.
>>>
>>> On Fri, 12 Aug 2016, Keith Stokes wrote:
>>>
>>> Route53 can get expensive for lots of domains. Queries are cheap with the
>>>> first 1M free, but if you have 1000 domains you’ll pay $500/month.
>>>>
>>>> You can build dedicated servers in multiple AZs and data centers able to
>>>> handle that many domains for far less.
>>>>
>>>> You might also consider running dedicated servers in each of AWS and
>>>> Azure to avoid a single-provider failure.
>>>>
>>>
>>>
>>> Having worked for AWS, there is no "global" control plane that would
>>> bring
>>> two regions down at the same time. While possible, due to say a targeted
>>> successful attack on both regions simultaneously, highly unlikely.
>>> Control
>>> and data plane software updates and deployments are done regionally, and
>>> often on an Availability Zone basis where applicable, to ensure there are
>>> no defects.  Automation measures and will automatically roll back code
>>> that
>>> breaks deployment metrics.
>>>
>>> It's pretty sweet. Their internal tools team does amazing things with
>>> automation.
>>>
>>> Route53 is $0.50 per month per "zone" (domain) for the FIRST 25, then
>>> $0.10
>>> per month per zone after that. 1000 domains would be $110 a month, not
>>> $500. 500 million queries at $0.40 per million, another $200/month.
>>>
>>> Who knows if you need that much, but it is pretty affordable.
>>>
>>> Beckman
>>> 
>>> ---
>>> Peter Beckman  Internet
>>> Guy
>>> beck...@angryox.com
>>> http://www.angryox.com/
>>> 
>>> ---
>>>
>>
>>

Re: DNS Services for a registrar

[Justin Paine via NANOG]

I won't push further than this -- but it seems a bit silly not to
mention that CloudFlare provides free AnyCast DNS. You can elect not
to even use any of our caching if you just want to use us for DNS.

J


Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Fri, Aug 12, 2016 at 12:24 PM, Peter Beckman  wrote:
> If there are other metrics in which to measure DNS speed, availability and
> redundancy, I'd love to seeing them. I have but my own datapoint and the
> metrics from others. Tear down the testing model, but at least show a
> different/better one in return.
>
> On Fri, 12 Aug 2016, Keith Stokes wrote:
>
>> Route53 can get expensive for lots of domains. Queries are cheap with the
>> first 1M free, but if you have 1000 domains you’ll pay $500/month.
>>
>> You can build dedicated servers in multiple AZs and data centers able to
>> handle that many domains for far less.
>>
>> You might also consider running dedicated servers in each of AWS and
>> Azure to avoid a single-provider failure.
>
>
> Having worked for AWS, there is no "global" control plane that would bring
> two regions down at the same time. While possible, due to say a targeted
> successful attack on both regions simultaneously, highly unlikely. Control
> and data plane software updates and deployments are done regionally, and
> often on an Availability Zone basis where applicable, to ensure there are
> no defects.  Automation measures and will automatically roll back code that
> breaks deployment metrics.
>
> It's pretty sweet. Their internal tools team does amazing things with
> automation.
>
> Route53 is $0.50 per month per "zone" (domain) for the FIRST 25, then $0.10
> per month per zone after that. 1000 domains would be $110 a month, not
> $500. 500 million queries at $0.40 per million, another $200/month.
>
> Who knows if you need that much, but it is pretty affordable.
>
> Beckman
> ---
> Peter Beckman  Internet Guy
> beck...@angryox.com http://www.angryox.com/
> ---

Re: EVERYTHING about Booters (and CloudFlare)

[Justin Paine via NANOG]

@Baldur

"They just lost all respect from here. Would someone from USA please report
these guys to the feds? What they are doing is outright criminal."

I'm happy to put you in touch with an FBI agent if you have questions
or concerns you'd like to discuss.


Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Thu, Jul 28, 2016 at 4:01 AM,   wrote:
> On Thu, 28 Jul 2016 12:00:00 +0200, Baldur Norddahl said:
>
>> DDoS attacks using stolen resources and fake identities is not legal
>
> Are you making a blanket statement that covers all jurisdictions on
> the planet?
>
> For bonus points - is it more like "illegal as in murder", or "illegal
> as in jaywalking"?  (Hint - which one will you get a DA to actually
> press a case that almost certainly crosses jurisdictions, and may involve
> extradition proceedings?)
>
>

Re: EVERYTHING about Booters (and CloudFlare)

[Justin Paine via NANOG]

>From our side:

 abuse@ reports generates an auto reply indicating where our reporting
form is located.

Reports at our reporting form generate an auto reply confirming we
received the report. All reports filed via the form are reviewed by a
human and at a minimum passed on to
the responsible hosting provider so they are aware and they can follow their
policies to address with their customer.


Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Wed, Jul 27, 2016 at 10:35 AM, Christopher Morrow
 wrote:
>
> On Wed, Jul 27, 2016 at 10:58 AM, Paras Jha 
> wrote:
>>
>> I consistently did not even get replies
>
>
> This is a common 'complaint' point for abuse senders. I often wonder why.
> What is a reply supposed to do or tell you?

Re: EVERYTHING about Booters (and CloudFlare)

[Justin Paine via NANOG]

Law enforcement (US or international) knows how to contact us if they
have an inquiry to make. We also publish a Transparency
Report that covers those legal inquiries:
https://www.cloudflare.com/transparency/


Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Wed, Jul 27, 2016 at 9:32 AM, Steve Atkins  wrote:
>
>> On Jul 27, 2016, at 9:17 AM, Baldur Norddahl  
>> wrote:
>>
>> Den 27. jul. 2016 17.12 skrev "Steve Mikulasik" :
>>>
>>> Disclaimer: I have a ton of respect for Clouldflare and what they do on
>> the internet.
>>
>> They just lost all respect from here. Would someone from USA please report
>> these guys to the feds? What they are doing is outright criminal.
>
> They can monitor (passively or actively) all access to the sites they host, 
> even
> the ones that use SSL, and they often use their close working relationship 
> with
> law enforcement to explain why they don't terminate bad actors on their 
> network.
>
> You can probably assume that "the feds" are intimately aware of what they're 
> doing.
>
> Cheers,
>   Steve
>

Re: EVERYTHING about Booters (and CloudFlare)

[Justin Paine via NANOG]

Hi Paras,

I covered the booter topic in a previous reply on a different (though
basically the same) thread. By "non-existent" you mean we are
processing thousands of reports per week. If you have something to
report you can certainly do so at cloudflare.com/abuse. We'd be more
than happy to process your report also.

Thanks,
Justin


Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D


On Wed, Jul 27, 2016 at 7:37 AM, Paras Jha  wrote:
> Hi Jair,
>
> This list is really interesting.
>
> From just a preliminary test, more than half of these domains are hiding
> behind Cloudflare, and OVH has a sizable fraction too. I suppose it's
> inevitable, given that both are known for having non-existent abuse
> departments.
>
> Regards
>
> On Wed, Jul 27, 2016 at 9:49 AM, Jair Santanna 
> wrote:
>
>> Hi folks,
>>
>> A friend forward me your topic about Booters and CloudFlare. Then I
>> decided to join the NANOG list. The *answer* for the first question about
>> CloudFlare and Booters is at: https://www.youtube.com/watch?v=wW5vJyI_HcU
>> (minute 45:55) given by the _CloudFlare CEO_ in the blackhat2013.
>>
>> I investigate Booters since 2013 and I know many (if not all) the possible
>> aspects about this DDoS-as-a-Service phenomenon. A summary of my entire
>> research (or large part of that) can be watched at
>> https://tnc16.geant.org/web/media/archive/3A (from minute 22:53). On top
>> of that, I developed an algorithm to find Booters and publicly share such
>> list (http://booterblacklist.com/). My main goal with this initiative is
>> to convince people to blacklist and keep on track the users that access
>> Booters (that potentially perform attacks)
>>
>> If you have any question about any aspect of the entire phenomenon don't
>> hesitate to contact me. By the way, I want to help deploy the booters
>> blacklist worldwide and help prosecutors to shutdown this bastards. I have
>> many evidences!
>>
>> Cheers,
>>
>> Jair Santanna
>> jairsantanna.com
>>
>>
>>
>>
>
>
> --
> Regards,
> Paras
>
> President
> ProTraf Solutions, LLC
> Enterprise DDoS Mitigation

Re: leap second outage

[Justin Paine via NANOG]

Any confirmation if the AWS outage was leap second-related?


Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP KeyID: 57B6 0114 DE0B 314D


On Tue, Jun 30, 2015 at 8:32 PM, Dovid Bender  wrote:
> I read that and that at midnight local time since that's when you have the 
> extra second. I know a large carrier in Israel is down. Waiting for conf. If 
> it's leep second related.
>
> --Original Message--
> From: Stefan
> Sender: NANOG
> To: frnk...@iname.com
> Cc: nanog@nanog.org
> Subject: Re: leap second outage
> Sent: Jun 30, 2015 23:30
>
> This was supposed to have happened @midnight UTC, right? Meaning that we
> are past that event. Under which scenarios should people be concerned about
> midnight local time? Lots of confusing messages flying all over...
> On Jun 30, 2015 10:13 PM,  wrote:
>
>> We experienced our first leap second outage -- our SHE (super head end) is
>> using (old) Motorola encoders and we lost those video channels.  They
>> restarted all those encoders to restore service.
>>
>> Frank
>>
>>
>
> Regards,
>
> Dovid