- NANOG - lists.nanog.org

Yahoo Postmaster or Email Admin
by Mark Stevens 29 Jul '16

29 Jul '16

Good Morning, If there is a Yahoo postmaster or email Admin that could contact me offline concerning a deferred IP address it would be great. Thanks Mark

6 11

Re: EVERYTHING about Booters (and CloudFlare)
by Scott Weeks 29 Jul '16

29 Jul '16

--- tknchris(a)gmail.com wrote: They don't discriminate, anyone can be a customer https://www.youtube.com/watch?v=T4GfoSZ_sDc great quote from the reporter "why do you need a court order to do the right thing?" ------------------------------------------ Holy crap that girl was painful to listen to! scott

2 1

Re: EVERYTHING about Booters (and CloudFlare)
by Alexander Maassen 28 Jul '16

28 Jul '16

Sigh, another long thread that goes nowhere in the end and simply dies a dull dead. So let's add my 2ct donation into it. First of all, CF like any other carrier/provider/hoster/whatever only cares about the bucks, nothing else, you all do to, so that should be clear enough. Them actually booting customers just because some other instance (except through govermential powers) wants them to is not done, as it would decrease the income. Period. Same goes for ISP's blocking access to resources. They will simply switch to another provider and or try to find workarounds for it (see pirate bay and the alikes). Thats like mopping the floor while the fire sprinklers are still on. Second, CF indeed offers DDoS mitigation, but only on their heavy paid plans, if you also want the netflow logs of the attacks etc, it will cost you extra. If you are on a free plan, and your assigned gw gets ddossed, and they figure out you are the target, they drop the 'protection' by simply changing dns to it's real values and letting the attacker know: don't dos us if you want to hit that site, use the real endpoint IP instead and you will hit them directly. (Been there with DroneBL, and as soon as I figured out they do that, dropped them immediately). In the end, you are better off at hosters like OVH/Foonet and such as they learned from the IRC age where it was common to nuke clients/bnc's in order to hijack nicknames/channels when the network didn't have channel/nick services. Third, for those who do not know it yet, CF only acts as an intermediate RELAY that provides a method of attempting to identify bad asses, nothing more. And the badasses they also relay for? Testpigs and informational source! (Keep your friends close, your enemies closer?). Hell, aren't some of the best security advisors former hackers? At least the ones I know used to be. And I rather have some decent hacker in my team, keeping me updated with the stuff thats going on in the scene, then some million dollar company trying to sell you crap that is always behind the facts. Oh, and I am talking about real hackers, not those scriptkiddies using ready made tools thinking they are god. Fourth, and I see it in this mail as well and a lot of others: The Jurisdictional issues. Why aren't there any international Cyber Crime laws yet? We all do need to enforce crap like DMCA (which the music/entertainment industry is responsible for), EU Cookie Law (which should have been handled through the browsers and not force it upon the websites) and it's inbread stupid derivates, but everyone, despite acting out international by it's presence on a global spanning network, is still hiding behind his/her's organizations local law. Kinda stupid, don't you agree ? Kind regards, Alexander Maassen Maintainer DroneBL On Thu, July 28, 2016 4:41 pm, Paul WALL wrote: > I'm sorry, but this entire discussion is predicated on half-truths and nonsense spewing out of the CF team. It's a shame too, as they're usually great community minded folks who are well respected around here. > > No matter how you define the CloudFlare service, that they can claim ignorance due to "common carrier" passthrough is preposterous, > especially given their purported knowledge of what's going on. > Likewise if the booter sites were connected to any other CDN, > WAF/proxy, public cloud provider, etc. Call it what you want, but at the end of the day, they're providing connectivity and keeping the storefront online. Want the problem stopped? Easy, stop it at the source by denying them service. Every service provider (or its > upstream at some point) has an AUP which prevents the service from being used for illegal purposes. Telling NANOG members that they don't understand the nature of the CF service, and that they should somehow get a pass, is dishonest. > > That they're keeping these criminals online at the requirement of the FBI? Anyone who's actually worked with law enforcement can tell you that the first rule of fight club is to NOT talk about it, especially if you're under gag order. A more likely story is they're just doing this for the attention, and basking in it, kind of like a certain blog post suggesting they pioneered the practice of configuring hosts with LACP for throughput and HA. > > If Justin/Matthew/Martin/etc. are listening, I implore you to do the right thing and stop providing service to criminals. Full stop, without caving in to your very talented marketing department. And to everyone else, I'd ask you to do what you think is right, and treat CloudFlare's anycasted IP blocks as you would any other network > harboring criminal activity and security risk to the detriment of your customers. (Is Team CYMRU listening?) Much like the original spam problem in the 90s, the collateral damage might be annoying at first, but the end will justify the means. > > Drive Slow (like a souped up Supra), > Paul Wall > > On Wed, Jul 27, 2016 at 10:48 PM, Randy Bush <randy(a)psg.com> wrote: >>> 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. >> >> hyperbole. it is not criminal. you just don't happen to like it. >

2 1

Yellow Pages - YP.ca sys/net admins
by Eric Dugas 27 Jul '16

27 Jul '16

Hello, Just trying to reach a clueful system or network admins from Yellow Pages. You can contact me off-list. Eric

1 0

Re: cloudflare hosting a ddos service?
by Steve Atkins 27 Jul '16

27 Jul '16

> On Jul 26, 2016, at 7:58 PM, Justin Paine <justin(a)cloudflare.com> wrote: > > Folks, > > "For a long time their abuse@ alias was (literally) routed to /dev/null. I'm not > sure whether that's still the case or whether they now ignore reports manually." > > @Steve It (literally) never was. :) Yes, it was. The smiley doesn't make your statement true. > The team I manage processes > reports all day > long. If you have a report to file certainly do so, > https://www.cloudflare.com/abuse I gave up on doing that in late 2014 after reporting thousands of pieces of spam advertising websites hosted by Cloudflare, with no action taken, no reply received, no ticket created, *nothing*. Not in response to mail sent to abuse@cloudflare, not in response to backchannel reports, not in response to mentions in person to staff at conferences. (This was mostly people selling lists of credit card numbers rather than booters, but it's the same sort of issue). Just to see what had changed, I went back to look at the sites I reported to Cloudflare in 2014. The couple I spot-checked are still hosted by Cloudflare. Given that you (Cloudflare, rather than you personally) haven't changed your policy of never terminating abusive websites you host then continuing to report them to you seems fairly pointless. > > > On the topic of booters: > > Short version -- As someone already mentioned, CloudFlare continues > not to be a hosting provider. That's untrue, of course. You terminate the http connection; you're hosting the website; you're hiding the identity of any other operators involved; you continue to serve the website even when the backing server has been terminated. Adding an interstitial for sites hosting malware is nice and all, but the problematic customers are the ones that are selling access to those malware compromised machines. You are taking sole responsibility by your actions, while denying all responsibility in your public statements. > > Our CEO has broadly covered this topic several times. > https://blog.cloudflare.com/thoughts-on-abuse/ > > Even if we removed our service the website does not go away,it > doesn't solve the problem if we temporarily stop providing DNS to the > domain(s). An often overlooked but extremely important note: there are > some situations where law > enforcement has required that we *not* terminate service to certain > websites. In those situations we are of course not allowed to discuss > specifics. Cheers, Steve

1 0

Re: cloudflare hosting a ddos service?
by Paras Jha 27 Jul '16

27 Jul '16

Justin, The only problem with that statement is that it's not true: if you did terminate service to them, the websites would go away. Maybe not today, but eventually. "Network stresser" owners are notorious for trying to take out the competition. Cloudflare provides free protection for these services to stay online. Most other ISPs wouldn't tolerate such shenanigans, whether it be for facilitating illegal activities or being on the receiving end of DDoS attacks, and would kick them off. On Tue, Jul 26, 2016 at 10:58 PM, Justin Paine <justin(a)cloudflare.com> wrote: > Folks, > > "For a long time their abuse@ alias was (literally) routed to /dev/null. > I'm not > sure whether that's still the case or whether they now ignore reports > manually." > > @Steve It (literally) never was. :) The team I manage processes > reports all day > long. If you have a report to file certainly do so, > https://www.cloudflare.com/abuse > > > On the topic of booters: > > Short version -- As someone already mentioned, CloudFlare continues > not to be a hosting provider. > > Our CEO has broadly covered this topic several times. > https://blog.cloudflare.com/thoughts-on-abuse/ > > Even if we removed our service the website does not go away, it > doesn't solve the problem if we temporarily stop providing DNS to the > domain(s). An often overlooked but extremely important note: there are > some situations where law > enforcement has required that we *not* terminate service to certain > websites. In those situations we are of course not allowed to discuss > specifics. > > ____________ > Justin Paine > Head of Trust & Safety > CloudFlare Inc. > PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D > > > On Tue, Jul 26, 2016 at 7:42 PM, Paras Jha <paras(a)protrafsolutions.com> > wrote: > > A five minute Google search revealed this, which is just the tip of the > > iceberg > > > > booter.xyz > > exitus.to > > zstress.net > > critical-boot.com > > instress.club > > webstresser.co > > anonymousstresser.com > > rawdos.com > > kronosbooter.com > > alphastress.com > > synergy.so > > str3ssed.me > > layer7.pw > > > > There are probably hundreds > > > > > > > > On Tue, Jul 26, 2016 at 10:33 PM, Paras Jha <paras(a)protrafsolutions.com> > > wrote: > > > >> This is quite common, almost all of the DDoS-for-hire services are > hosted > >> behind CloudFlare, and a great majority of them take PayPal. Another one > >> had even managed to secure an EV SSL cert. > >> > >> On Tue, Jul 26, 2016 at 10:24 PM, Dovid Bender <dovid(a)telecurve.com> > >> wrote: > >> > >>> I used to have a boss that was convinced that MCafee was writing > viruses > >>> to stay in business.... > >>> > >>> Regards, > >>> > >>> Dovid > >>> > >>> -----Original Message----- > >>> From: Phil Rosenthal <pr(a)isprime.com> > >>> Sender: "NANOG" <nanog-bounces(a)nanog.org>Date: Tue, 26 Jul 2016 > 22:17:53 > >>> To: jim deleskie<deleskie(a)gmail.com> > >>> Cc: NANOG list<nanog(a)nanog.org> > >>> Subject: Re: cloudflare hosting a ddos service? > >>> > >>> Plus, it’s good for business! > >>> > >>> -Phil > >>> > >>> > On Jul 26, 2016, at 10:14 PM, jim deleskie <deleskie(a)gmail.com> > wrote: > >>> > > >>> > sigh... > >>> > > >>> > On Tue, Jul 26, 2016 at 10:55 PM, Patrick W. Gilmore < > patrick(a)ianai.net > >>> > > >>> > wrote: > >>> > > >>> >> CloudFlare will claim they are not hosting the problem. They are > just > >>> >> hosting the web page that lets you pay for or points at or otherwise > >>> >> directs you to the problem. > >>> >> > >>> >> The actual source of packets is some other IP address. Therefore, > they > >>> can > >>> >> keep hosting the web page. It is not sending the actual > >>> >> [spam|DDoS|hack|etc.], right? So stop asking them to do something > >>> about it! > >>> >> > >>> >> Whether you think that is the proper way to provide service on the > >>> >> Internet is left as an exercise to the reader. > >>> >> > >>> >> -- > >>> >> TTFN, > >>> >> patrick > >>> >> > >>> >>> On Jul 26, 2016, at 9:49 PM, Mike <mike-nanog(a)tiedyenetworks.com> > >>> wrote: > >>> >>> > >>> >>> Hi, > >>> >>> > >>> >>> So vbooter.org's dns and web is hosted by cloudflare? > >>> >>> > >>> >>> "Using vBooter you can take down home internet connections, > websites > >>> and > >>> >> game servers such us Minecraft, XBOX Live, PSN and many more." > >>> >>> > >>> >>> dig -t ns vbooter.org > >>> >>> > >>> >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org > >>> >>> ;; global options: +cmd > >>> >>> ;; Got answer: > >>> >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177 > >>> >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: > 1 > >>> >>> > >>> >>> ;; OPT PSEUDOSECTION: > >>> >>> ; EDNS: version: 0, flags:; udp: 512 > >>> >>> ;; QUESTION SECTION: > >>> >>> ;vbooter.org. IN NS > >>> >>> > >>> >>> ;; ANSWER SECTION: > >>> >>> vbooter.org. 21599 IN NS rick.ns.cloudflare.com. > >>> >>> vbooter.org. 21599 IN NS amy.ns.cloudflare.com. > >>> >>> > >>> >>> dig -t a www.vbooter.org > >>> >>> > >>> >>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org > >>> >>> ;; global options: +cmd > >>> >>> ;; Got answer: > >>> >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920 > >>> >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: > 1 > >>> >>> > >>> >>> ;; OPT PSEUDOSECTION: > >>> >>> ; EDNS: version: 0, flags:; udp: 512 > >>> >>> ;; QUESTION SECTION: > >>> >>> ;www.vbooter.org. IN A > >>> >>> > >>> >>> ;; ANSWER SECTION: > >>> >>> www.vbooter.org. 299 IN CNAME vbooter.org. > >>> >>> vbooter.org. 299 IN A 104.28.13.7 > >>> >>> vbooter.org. 299 IN A 104.28.12.7 > >>> >>> > >>> >>> > >>> >>> Can anyone from cloudflare answer me why this fits with your > >>> business > >>> >> model? > >>> >>> > >>> >>> Mike- > >>> >> > >>> >> > >>> > >>> > >> > >> > >> -- > >> Regards, > >> Paras > >> > >> President > >> ProTraf Solutions, LLC > >> Enterprise DDoS Mitigation > >> > > > > > > > > -- > > Regards, > > Paras > > > > President > > ProTraf Solutions, LLC > > Enterprise DDoS Mitigation > -- Regards, Paras President ProTraf Solutions, LLC Enterprise DDoS Mitigation

1 1

cloudflare hosting a ddos service?
by Mike 27 Jul '16

27 Jul '16

Hi, So vbooter.org's dns and web is hosted by cloudflare? "Using vBooter you can take down home internet connections, websites and game servers such us Minecraft, XBOX Live, PSN and many more." dig -t ns vbooter.org ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;vbooter.org. IN NS ;; ANSWER SECTION: vbooter.org. 21599 IN NS rick.ns.cloudflare.com. vbooter.org. 21599 IN NS amy.ns.cloudflare.com. dig -t a www.vbooter.org ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.vbooter.org. IN A ;; ANSWER SECTION: www.vbooter.org. 299 IN CNAME vbooter.org. vbooter.org. 299 IN A 104.28.13.7 vbooter.org. 299 IN A 104.28.12.7 Can anyone from cloudflare answer me why this fits with your business model? Mike-

11 13

Speedtest.net not accessible in Chrome due to deceptive ads
by Janusz Jezowicz 27 Jul '16

27 Jul '16

Since this morning Speedtest.net is not accessible in Chrome Reason: https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.sp… For any ISPs/content providers linking to speedtest.net you may want to swap links to a different website or host your own speed test. e.g. Netflix at http://fast.com Regards, Janusz Jezowicz *Speedchecker Ltd* *email*: janusz(a)speedchecker.xyz *skype*: jezowicz *phone*: +442032863573 *web*: www.speedchecker.xyz The Black Church, St. Mary’s Place, Dublin 7, D07 P4AX, Ireland

16 22

Notice about project to roll the root zone KSK
by Matt Larson 26 Jul '16

26 Jul '16

I realize DNS operational content isn't the usual NANOG fare, but rolling the root zone KSK for the first time is a significant-enough event that I wanted to send to this list anyway. TL;DR: The root zone KSK is changing on October 11, 2017 (yes, over a year away). If you're doing DNSSEC validation, you should care. If you're not the DNS person in your organization, please pass this notice on to that person. If the topic interests you, more information is below. Matt -- Matt Larson VP of Research Office of the CTO, ICANN > Begin forwarded message: > > From: Matt Larson <matt.larson(a)icann.org> > Subject: Plan documents for root KSK roll project now available > Date: July 26, 2016 at 8:59:45 AM EDT > To: <ksk-rollover(a)icann.org> > > On Friday, July 22, in the interests of transparency and to notify the DNS operational community, ICANN posted plans <https://www.icann.org/resources/pages/ksk-rollover#operational-plans> to roll the root zone key signing key (KSK). These plans were developed by the Root Zone Management Partners: ICANN in its role as the IANA Functions Operator, Verisign acting as the Root Zone Maintainer, and the U.S. Department of Commerce's National Telecommunications and Information Administration (NTIA) as the Root Zone Administrator. The plans incorporate the March 2016 recommendations <https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf> of the Root Zone KSK Rollover Design Team, after it sought and considered public comment <https://www.icann.org/news/announcement-2013-03-08-en> on a proposed rollover process. > > The process of creating a new key, using it to sign the root DNSKEY RRset and securely destroying the old key will start in Q4 2016 and last until Q3 2016, though the portions resulting in visible changes in DNS occur between Q3 2016 and Q1 2017. The important milestones in the project are: > > - October 26, 2016: The new KSK is generated in ICANN's U.S. East Coast key management facility (KMF). > - February, 2017: The new KSK is copied to ICANN's U.S. West Coast KMF and is considered operationally ready, and ICANN publishes the new key at https://data.iana.org/root-anchors/root-anchors.xml <https://data.iana.org/root-anchors/root-anchors.xml>. (The exact date is dependent on the timing of the Q1 2017 key ceremony, which has not yet been scheduled.) > - July 11, 2017: The new KSK appears in the root DNSKEY RRset for the first time. > - October 11, 2017: The new KSK signs the root DNSKEY RRset (and the old KSK no longer signs). This date is the actual KSK rollover. > - January 11, 2018: The old KSK is published as revoked (per RFC 5011, "Automated Updates of DNS Security"). > > What you need to do > > If you operate any software performing DNSSEC validation (such as a security-aware recursive name server) that implements the RFC 5011 automated trust anchor update protocol and this functionality is enabled, you have no action: your software will notice the new KSK (authenticated by the old KSK) and update its trust anchor store accordingly. > > If you operate any software performing DNSSEC validation that does not implement RFC 5011 or if you don't use the RFC 5011 protocol, you will need to update your software's trust anchor configuration manually to add the new KSK before October 11, 2017. You can obtain the new KSK in February, 2017, using one of the methods described in the "Trust Anchor Publication" section of 2017 KSK Rollover Operational Implementation Plan <https://www.icann.org/en/system/files/files/ksk-rollover-operational-implem…> (one of the aforementioned recently published plans). > > If you write, package or distribute software that performs DNSSEC validation and you hard code the root KSK (e.g., in code or configuration files), you should update your software with the new KSK when it becomes available in February, 2017. > > Staying informed > > ICANN will post occasional notices to various operational forums to keep the community informed of this project's progress, but we strongly suggest that anyone with an interest subscribe to the root KSK rollover mailing list <https://mm.icann.org/mailman/listinfo/ksk-rollover> operated by ICANN (ksk-rollover(a)icann.org <mailto:ksk-rollover@icann.org>). The list is extremely low volume. > > The ICANN staff supporting and implementing the root KSK rollover project welcome your questions and comments: please direct them to the ksk-rollover(a)icann.org <mailto:ksk-rollover@icann.org> list. > > Matt > -- > Matt Larson > VP of Research > Office of the CTO, ICANN >

1 0

Clueful BGP from TW-Telecom/L3
by Scott Morris 26 Jul '16

26 Jul '16

Is there per chance anyone hanging on here who is clueful about BGP working with TW-Telecom and the recent integration with Level3???? I have a client that I consult with whose route is not getting sent from TW to L3 and the techs on the case are convinced we need to put different BGP communities in (both to TW link and other provider link) which of course we are putting in to satisfy them, but magically it is not working. This SHOULD be an easy thing to figure out using the Looking Glass servers within both TW and Level3, but this concept is lost on techs we are dealing with. Anyone internal there who can contact me off-list would be greatly appreciated! Scott swm(a)emanon.com

1 0