Re: Ransom DDoS attack - need help!

[Anne Mitchell]

Sorry this is so late, I get NANOG in Digest Mode...

> I would really appreciate help in a few areas (primarily with certain
> provider contacts/intros) so we can execute our strategy (which I can't
> reveal here for obvious reasons). If you email me off-list with a
> name/email that you've previously used on-list, I will reply from my real
> email.
> 
> Alternatively, if you can post your experiences on-list with large scale
> high profile ransom DDoS attacks, I'd really appreciate it!

Please contact me offlist, and I will introduce you to the person who says the 
below - they are from $ENORMOUS-ESP, and were deeply involved in the efforts 
during last year's rounds of ransom DDoSs which saw many different targets 
coordinating in fending off the attacks (and working with the FBI).  The 
basecamp group to which he refers is the group of all of the different NOC and 
architect folks from the various companies, who strategized together, and all 
of their info is still there.  I'm familiar with this all as I was part of the 
coordination efforts, as so many of the targets also happened to be customers 
of ours and, you know, lawyer. ;-)

He says:

"I'm happy to invite him to the basecamp if he wants access, just need his 
email.

Otherwise, feel free to share with him that others ended up using prolexic OR 
whatever the other large provider is out there. that seems to be the universal 
solution if they don't want to buy gear and roll their own solution. Amazon and 
Google cloud environments aren't impervious from this stuff, but they are 
getting better, and using some of the same technology."

---

Anne

Anne P. Mitchell, 
Attorney at Law
CEO/President, 
SuretyMail Email Reputation Certification
Is Email You Send Being Junked? Get to the Inbox Using Your Own Mail System!
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

"Email marketing is the one place where it's better to ask permission than 
forgiveness." - Me

Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Member, California Bar Cyberspace Law Committee
Member, Colorado Cybersecurity Consortium
Ret. Professor of Law, Lincoln Law School of San Jose
303-731-2121 | amitch...@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell  | LinkedIn/in/annemitchell

Re: Ransom DDoS attack - need help!

[alvin nanog]

hi ya roland

On 12/04/15 at 11:09am, Roland Dobbins wrote:
> On 4 Dec 2015, at 9:34, alvin nanog wrote:
> >all that tcpdump jibberish
> 
> Is entirely unnecessary, as well as being completely impractical on a
> network of any size.

up to a point, probing around at the packet level is un-necessary depending
on what one is looking for as the end result

> Reasonable network access policies for the entities under attack plus flow
> telemetry collection/analysis, S/RTBH, and/or flowspec are a good start,
> along with this:

flows may address some of the DDoS issues but might not cover all
the various DDoS attacks and mitigation options and still stay within the
victims possibly non-existent DDoS mitigation budgets

> This business of attempting to use packet captures for everything is the
> equivalent of your doctor attempting to diagnose the reason you're running a
> fever by using an electron microscope.

sometimes, one does need to be able to crawl, before walking, before
running track vs running marathons or find someone that can run for you

in the case of ddos mitigation, no one solution can mitigate against all
the possible various attacks... mitigation is a multi-layered solutions

- who-what-when-where-how-why-etc:

- one does need to know what servers, ports and hw is being attacked

  it makes DDoS mitigation a lot easier if you know what is under attack
  and orders of magnitude less expensive to mitigate

- one does need to know who is attacking

  if one cannot defend against low level script kiddie ddos attacks, 
  it's unlikely one will survive a ddos attacks from a more skilled attacker
  determined to take out a server or break in etc

  if you can and have defended against all the basic script kiddie ddos attacks,
  then it might make it easier to find the next set of the various
  ddos mitigation options you need to take 

- one does need to know how often, what time, they are attacking

  if they are attacking after hours, some folks might not care compared
  to they attacking during regular business hours

- one does need to know how much traffic the attacks are costing you
  in terms of time and loss of productivity due to wasted bandwidth

  even at 10% of your bandwidth used up by useless DDoS traffic is still
  noticibly annoying if you were to looking to increase network performance

- nobody can really say why they are attacking, other than are you
  a low level fruit for easy picking or a target'd victim for
  many reasons ( paid ransom before, high profile servers, a bank, 
  govt servers, etc ) .. pay once and all the other DDoS ransom attackers
  will come knocking to collect their share

> Start with the BCPs, then move to the macroanalytical.  Only dip into the
> microanalytical when required, and even then, do so very selectively.

yup... selective and escalate the migitation process and procedure

magix pixie dust
alvin

Re: Staring Down the Armada Collective

[dennis]

I agree Protonmail took a stance and believe many others can learn from their 
experience. But let's not over simplify the problem. According to their blogs 
the attacks were over 100G and went on for hours at a time over several days.  
Attacks can go on for days and months.  Protonmail found themselves up against 
varying attack tactics and ultimately  took a defense in depth approach to 
mitigate the attack. 
Null routing original ip completes the attack, game over , sever is down. 
Granted this can help prevent colateral damages.  Combined with proxies can 
work well for dns redirect to route through cloud scrubbing but these solutions 
can add latency and impact legitimate traffic also. With redirection there is 
also the complexity of TLS/SSL (certificate management,  privacy, etc.) And 
then you must also consider ip based (non proxied) targets.   These dns 
redirect/proxy methods don't handle ip based attack targets and cause the need 
to swing ip prefixes via bgp. Bottom line, attackers can impact the 
infrastructure by varying their tactics and the approach should be well thought 
out and multilayered.


Sent via the Samsung GALAXY S® 5, an AT 4G LTE smartphone

 Original message 
From: Lyndon Nerenberg  
Date: 12/4/2015  12:14 AM  (GMT-05:00) 
To: North American Network Operators' Group  
Subject: Re: Staring Down the Armada Collective 


On Dec 3, 2015, at 6:28 PM, Lyndon Nerenberg  wrote:

> Are we perhaps, finally, reaching the cusp where everyone has realized that 
> if we all, collectively, tell the rodents to f*** off, they just might?

I should also mention that, despite their bluster, they can't keep it up for 
more than half an hour.

By then, the upstream networks have figured it out and have null routed 
anything of consequence - far upstream.  Meanwhile, back haul your traffic in 
via a private network and they won't be able to do shit to you. (E.g. the 
standard Cloudflare model.)

They are not as smart as they make themselves out to be.  Don't let fear drive 
your decisions.

--lyndon

Re: IPv6 Cogent vs Hurricane Electric

[Paul WALL]

On Tue, Dec 1, 2015 at 7:34 PM, Jeff Walter  wrote:
> That cake will haunt NANOG until the end of time.
>
> On Tue, Dec 1, 2015 at 12:01 PM, Alarig Le Lay  wrote:
>
>> On Tue Dec  1 14:39:14 2015, Andrew Kirch wrote:
>> > Might I suggest cake pleas?
>>
>> You mean
>>
>> http://www.datacenterknowledge.com/wp-content/uploads/2009/10/Hurricane-Cake.jpg
>> ?
>>


i mean

"Different companies have different personalities, and the vast
majority work through their relationships fine in the interest of the
public and the industry.  But there are always a few companies that
like to act out on the public stage to achieve their business
objectives."

  --Mike Leber, 6/29/15 Telecom Ramblings

along with the bad spelling, we have short memories.  peering is about
mutual benefits. when benefits aren't there peering doesn't happen.
going to nanog and yelling about peering by saying that you're a
victim isn't a mutual benefit last i checked. their lack of peering
doesn't demand another moment of our attention. choose wisely.

Drive slow,
Paul WALL

eBay contact that deals with IPv6

[Frank Bulk]

I'm looking for an eBay network engineer to contact me off-list that can dig
into an IPv6 performance issue. I started monitoring ipv6.ebay.com a week or
two ago and the site times out (10 second timer) regularly.  The last seven
days indicate it's been timing out about one-third of the time.

Frank

Re: IPv6 Cogent vs Hurricane Electric

[Matthew Petach]

On Fri, Dec 4, 2015 at 5:43 PM, Randy Bush  wrote:
>> Or, if you feel that Cogent's stubborn insistence on partitioning the
>> global v6 internet
>
> if A does not peer with B,
> then for all A and B
> they are evil partitioners?
>
> can we lower the rhetoric?
>
> randy
>



I thought we already had this conversation
a few years ago, but my memory is short,
so we can have it again.   ^_^;

No, it's not an issue of A not peering
with B, it's A selling "internet transit"
for a known subset of the internet
rather than the whole kit and kaboodle.

I rather think that if you're going to put
a sign out saying "we sell internet transit",
it *is* incumbent on you to make a best
effort to ensure you have as complete
a copy of the full routing table as possible;
otherwise, it's potentially a fraudulent claim.
At least, that's what it would be in any other
industry if you sold something under a particular
name while knowing the whole time it didn't
fit the definition of the product.

I know in the service station industry,
I'd get in a lot of trouble if I sold "premium
unleaded gasoline" that was really just the
same as the "regular unleaded" with a
different label.  It's fortunate that we're
not a regulated industry, so there's nobody
checking up on us to make sure that if
we sell "internet transit", it's not really
"internet transit, minus level3, sprint, ATT,
and a bunch of other networks that won't
get your prefixes from me".

It all boils down to 'caveat emptor' -- not all
uses of the word "internet transit" mean the
same thing--check carefully when buying, and
make sure you make informed decisions.

Matt
(now with 50% less rhetoric!)

Re: IPv6 Cogent vs Hurricane Electric

[Paul S.]

It is worth noting that HE indeed provides the full view, it's the other 
side that has an issue.


(Since HE isn't really a tier 1, their transit relationships with Telia 
and other carriers "save" them)


Cogent -> HE dies with unreachable on the first hop though, and that's 
an issue for Cogent customers.


On 12/5/2015 11:09 AM, Baldur Norddahl wrote:

On 5 December 2015 at 02:43, Randy Bush  wrote:


Or, if you feel that Cogent's stubborn insistence on partitioning the
global v6 internet

if A does not peer with B,
then for all A and B
they are evil partitioners?

can we lower the rhetoric?


They both loses on this. In fact anyone claiming tier 1 status loses here,
because this illustrates why you can never be single homed on a tier 1
network. These guys simply do not have the full internet.

Regards,

Baldur

Re: IPv6 Cogent vs Hurricane Electric

[Randy Bush]

> No, it's not an issue of A not peering
> with B, it's A selling "internet transit"
> for a known subset of the internet
> rather than the whole kit and kaboodle.

right.  then hurricane and cogent should both
make clear that they do not provide ipv6 transit
to the entire internet.

randy

Re: IPv6 Cogent vs Hurricane Electric

[Randy Bush]

> Or, if you feel that Cogent's stubborn insistence on partitioning the
> global v6 internet

if A does not peer with B,
then for all A and B
they are evil partitioners?

can we lower the rhetoric?

randy

Re: IPv6 Cogent vs Hurricane Electric

[Paul S.]

Whoops, spoke too soon.

While HE indeed seems to use the transits to reach Cogent, they only do 
this over v4.


IPv6 packets are indeed dropped on the first border. Sorry for the noise.

core1.fmt1.he.net> traceroute ipv6 2001:550:2:d::a:2 numericTarget 
2001:550:2:d::a:2

Hop Start   1
Hop End 30

Hop Packet 1Packet 2Packet 3Hostname
1   *   *   *   ?
2   *   *   *   ?
3   *   *   *   ?
4   *   *   *   ?
IP: Errno(8) Trace Route Failed, no response from target node.




On 12/5/2015 11:43 AM, Paul S. wrote:
It is worth noting that HE indeed provides the full view, it's the 
other side that has an issue.


(Since HE isn't really a tier 1, their transit relationships with 
Telia and other carriers "save" them)


Cogent -> HE dies with unreachable on the first hop though, and that's 
an issue for Cogent customers.


On 12/5/2015 11:09 AM, Baldur Norddahl wrote:

On 5 December 2015 at 02:43, Randy Bush  wrote:


Or, if you feel that Cogent's stubborn insistence on partitioning the
global v6 internet

if A does not peer with B,
then for all A and B
they are evil partitioners?

can we lower the rhetoric?

They both loses on this. In fact anyone claiming tier 1 status loses 
here,

because this illustrates why you can never be single homed on a tier 1
network. These guys simply do not have the full internet.

Regards,

Baldur

Re: IPv6 Cogent vs Hurricane Electric

[William Herrin]

On Fri, Dec 4, 2015 at 8:43 PM, Randy Bush  wrote:
>> Or, if you feel that Cogent's stubborn insistence on partitioning the
>> global v6 internet
>
> if A does not peer with B,
> then for all A and B
> they are evil partitioners?
>
> can we lower the rhetoric?

It's Cogent. Seriously. They earned their disrespect.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: IPv6 Cogent vs Hurricane Electric

[Baldur Norddahl]

On 5 December 2015 at 02:43, Randy Bush  wrote:

> > Or, if you feel that Cogent's stubborn insistence on partitioning the
> > global v6 internet
>
> if A does not peer with B,
> then for all A and B
> they are evil partitioners?
>
> can we lower the rhetoric?
>

They both loses on this. In fact anyone claiming tier 1 status loses here,
because this illustrates why you can never be single homed on a tier 1
network. These guys simply do not have the full internet.

Regards,

Baldur

Re: IPv6 Cogent vs Hurricane Electric

[Josh Reynolds]

Is "tier" even a thing anymore?
On Dec 4, 2015 8:46 PM, "Paul S."  wrote:

> It is worth noting that HE indeed provides the full view, it's the other
> side that has an issue.
>
> (Since HE isn't really a tier 1, their transit relationships with Telia
> and other carriers "save" them)
>
> Cogent -> HE dies with unreachable on the first hop though, and that's an
> issue for Cogent customers.
>
> On 12/5/2015 11:09 AM, Baldur Norddahl wrote:
>
>> On 5 December 2015 at 02:43, Randy Bush  wrote:
>>
>> Or, if you feel that Cogent's stubborn insistence on partitioning the
 global v6 internet

>>> if A does not peer with B,
>>> then for all A and B
>>> they are evil partitioners?
>>>
>>> can we lower the rhetoric?
>>>
>>> They both loses on this. In fact anyone claiming tier 1 status loses
>> here,
>> because this illustrates why you can never be single homed on a tier 1
>> network. These guys simply do not have the full internet.
>>
>> Regards,
>>
>> Baldur
>>
>
>

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 05 Dec, 2015

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  571357
Prefixes after maximum aggregation (per Origin AS):  212309
Deaggregation factor:  2.69
Unique aggregates announced (without unneeded subnets):  278305
Total ASes present in the Internet Routing Table: 52177
Prefixes per ASN: 10.95
Origin-only ASes present in the Internet Routing Table:   36655
Origin ASes announcing only one prefix:   15946
Transit ASes present in the Internet Routing Table:6383
Transit-only ASes present in the Internet Routing Table:165
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  35
Max AS path prepend of ASN ( 55644)  31
Prefixes from unregistered ASNs in the Routing Table:  1028
Unregistered ASNs in the Routing Table: 367
Number of 32-bit ASNs allocated by the RIRs:  11965
Number of 32-bit ASNs visible in the Routing Table:9139
Prefixes from 32-bit ASNs in the Routing Table:   34775
Number of bogon 32-bit ASNs visible in the Routing Table:14
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:421
Number of addresses announced to Internet:   2802085056
Equivalent to 167 /8s, 4 /16s and 108 /24s
Percentage of available address space announced:   75.7
Percentage of allocated address space announced:   75.7
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   97.8
Total number of prefixes smaller than registry allocations:  188133

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   144487
Total APNIC prefixes after maximum aggregation:   39866
APNIC Deaggregation factor:3.62
Prefixes being announced from the APNIC address blocks:  152684
Unique aggregates announced from the APNIC address blocks:60777
APNIC Region origin ASes present in the Internet Routing Table:5113
APNIC Prefixes per ASN:   29.86
APNIC Region origin ASes announcing only one prefix:   1190
APNIC Region transit ASes present in the Internet Routing Table:895
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 34
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1719
Number of APNIC addresses announced to Internet:  756067456
Equivalent to 45 /8s, 16 /16s and 172 /24s
Percentage of available APNIC address space announced: 88.4

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 131072-135580
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:180946
Total ARIN prefixes after maximum aggregation:88978
ARIN Deaggregation factor: 2.03
Prefixes being announced from the ARIN address blocks:   184304
Unique aggregates announced from the ARIN address blocks: 86632
ARIN Region origin ASes present in the Internet Routing Table:16512

Re: Netflow parameters and data that comes from CDNs

[Danijel Starman]

Hi,


> And in fictitious case of jf_music.com hiring Akamai, would the Akamai
> server(s)  have a dedicated IP for jf_music in each city (or re-use same
> IP via anycast)  or would the CDN servers use the same IP address to
> deliver multiple services from totally different content providers ?
>

Generally the CDN provider would have a cluster of machines/IP's on each of
their locations that are reused by different customers and are probably
divided by service/content. They would probably be stable but can vary due
to service improvements or disruptions. As it was noted Akamai is putting
servers into the ISP's, I don't think that others like L3 or Limelight do
it (or seen evidence that they do).