Re: backtracking forged packets?

[Jean | ddostest.me via NANOG]

I believe that Oculus blocked the RST and not the SYN/ACK.

It sounds the same but, it's not.

I see 2 options here:

1. Continue to be DDoS and abuse. The result is maybe they will move on, 
but I doubt.


2. Try to block the malformed SYN/ACK and it will probably solve your 
issue. You have nothing to lose to try as you can easily fallback.


You can let us know what are the results and if I was wrong, I will 
publicly state that I was wrong.


But, make sure you do it properly. _Do not block the RST_, you need to 
block the malformed SYN/ACK before they hit your open reflectors.


Jean


On 2020-03-15 12:05, Amir Herzberg wrote:
Bill: I agree with Damian that you should try to ensure responding 
with RST to SYN/ACK; in fact, attackers are sometimes (often?) 
_looking_ for networks that do not send RST in response to unsolicited 
SYN/ACK, to spoof their addresses in syn-flooding and other attacks 
(eg., syn-ack) against victim servers.


Not sending RST could even result in you receiving ICMP unreachable - 
esp. indicating filtering as you received - since server admins may 
have installed a filter against your prefix (to deal with such abuse). 
So, I wonder, it is possible that your network/FW/provider already 
filter the RST responses so they don't reach the (victim) servers?


BTW, I'm covering these issues in my DoS lecture as part of the 
Net-Sec course (see URL below). The foils are available (although not 
yet latest version, will upload `soon' :) ), the text of the net-sec 
(2nd) part - not so much, it may take me quite a while to make this 
(2nd) part useable.

--
Amir Herzberg

Comcast professor of Security Innovations, University of Connecticut

Homepage: https://sites.google.com/site/amirherzberg/home

Foundations of Cyber-Security (part I: applied crypto, part II: 
network-security):

https://www.researchgate.net/project/Foundations-of-Cyber-Security



On Sat, Mar 14, 2020 at 7:51 PM Damian Menscher via NANOG 
mailto:nanog@nanog.org>> wrote:


I don't recommend filtering the SYN-ACK packets.  That's what
Octolus did, and the result was leaving half-open SYN_RECV
connections on all the nodes used for reflection.  That has two
downsides:

  - the reflectors will retry the SYN-ACK (several times), which
increases your PPS load (amplifying the attack)
  - the providers may notice the large number of SYN_RECV
connections from your network and put you on a blacklist

I don't want to leave you with the impression that it's
hopeless... these attacks aren't impossible to stop --- it just
requires convincing the transit providers to care.

Damian

On Sat, Mar 14, 2020 at 1:31 PM Jean | ddostest.me
 via NANOG mailto:nanog@nanog.org>> wrote:

Hi Bill,

thanks for sharing the data. Indeed, I can't offer you a way
to backtrack the spoofed packets.

Anyway, I'm not sure what could you do legally as there is a
very high chance that these people are not in the USA and the
CFAA won't apply to them.

Here is what I would do if I was in your situation.

Since these packets are spoof and malformed, I would block all
SYN/ACK based on the length.

Depending on your hardware, it's very easy to inspect _only
the SYN/ACK by length_ if you have modern hardware. On
linux/unix, it's also very straightforward. I'm not sure for
windows though.

Here is the details of the analysis:

Today, all the SYN and SYN/ACK includes a minimum of options
like MSS, WS, SACK, NOP (Only a spacer, sometimes 2) and
extended TS. There might be others, but let's use the basic one.

In your case, there are none. There is only MSS and the SYN
length is 44 bytes. These are spoof packets maybe generated by
either TCP-AMP like reported earlier.

I would try to block all SYN/ACK coming toward your network
with a length of 44 bytes or lower. But, this is weird because
it should be 54 bytes. Maybe there is some offloading of some
sort in your gear.

Now depending on your hardware, it could work or it could kill
your router as it will punt the cpu. I guess you have some
modern gear.

What I do when I am not sure about the length, I start to
accept and log at 60 bytes, then 58, 56, 54... 44 until I
catch the gremlins.

Once you found the sweet spot, you drop all SYN/ACK toward
your /23 lower than X bytes. It won't kill or block anything
legitimate if you do it properly. :)

What will happen is that you will not reply to these spoof
SYN/ACK with a RST and still allowing RST for legit SYN and
SYN/ACK. Akamai and your service providers will be happy and
should not penalize you.

I'm pretty sure that it will help you as it did for me in the
past.

Let me know if 

Re: backtracking forged packets?

[Jean | ddostest.me via NANOG]

Hi Bill,

thanks for sharing the data. Indeed, I can't offer you a way to 
backtrack the spoofed packets.


Anyway, I'm not sure what could you do legally as there is a very high 
chance that these people are not in the USA and the CFAA won't apply to 
them.


Here is what I would do if I was in your situation.

Since these packets are spoof and malformed, I would block all SYN/ACK 
based on the length.


Depending on your hardware, it's very easy to inspect _only the SYN/ACK 
by length_ if you have modern hardware. On linux/unix, it's also very 
straightforward. I'm not sure for windows though.


Here is the details of the analysis:

Today, all the SYN and SYN/ACK includes a minimum of options like MSS, 
WS, SACK, NOP (Only a spacer, sometimes 2) and extended TS. There might 
be others, but let's use the basic one.


In your case, there are none. There is only MSS and the SYN length is 44 
bytes. These are spoof packets maybe generated by either TCP-AMP like 
reported earlier.


I would try to block all SYN/ACK coming toward your network with a 
length of 44 bytes or lower. But, this is weird because it should be 54 
bytes. Maybe there is some offloading of some sort in your gear.


Now depending on your hardware, it could work or it could kill your 
router as it will punt the cpu. I guess you have some modern gear.


What I do when I am not sure about the length, I start to accept and log 
at 60 bytes, then 58, 56, 54... 44 until I catch the gremlins.


Once you found the sweet spot, you drop all SYN/ACK toward your /23 
lower than X bytes. It won't kill or block anything legitimate if you do 
it properly. :)


What will happen is that you will not reply to these spoof SYN/ACK with 
a RST and still allowing RST for legit SYN and SYN/ACK. Akamai and your 
service providers will be happy and should not penalize you.


I'm pretty sure that it will help you as it did for me in the past.

Let me know if it's not clear and/or which part is foggy and I'll try to 
give more details and better explanation.


Regards,

Jean St-Laurent

On 2020-03-14 11:46, William Herrin wrote:

On Sat, Mar 14, 2020 at 4:02 AM Jean | ddostest.me via NANOG
 wrote:

can you post some forged packets please? You can send them offlist if
you prefer.

Hi Jean,

Here are a couple examples (PDT this morning):

08:22:43.413250 IP (tos 0x0, ttl 55, id 10108, offset 0, flags [none],
proto ICMP (1), length 56)
 45.89.93.26 > 199.33.225.218: ICMP host 45.89.93.26 unreachable -
admin prohibited filter, length 36
 IP (tos 0x0, ttl 69, id 10108, offset 0, flags [DF], proto TCP
(6), length 40)
 199.33.225.218.9851 > 45.89.93.26.443: [|tcp]
 0x:  4500 0038 277c  3701 28da 2d59 5d1a
 0x0010:  c721 e1da 030d 4b61   4500 0028
 0x0020:  277c 4000 4506 dae4 c721 e1da 2d59 5d1a
 0x0030:  267b 01bb a057 e903

08:25:47.787326 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto
TCP (6), length 44)
 104.87.78.95.80 > 199.33.225.143.8667: Flags [S.], cksum 0xc97a
(correct), seq 1216155085, ack 11765035, win 29200, options [mss
1156], length 0
 0x:  4500 002c  4000 3606 e564 6857 4e5f
 0x0010:  c721 e18f 0050 21db 487d 0dcd 00b3 852b
 0x0020:  6012 7210 c97a  0204 0484

I have observed no consistency in the remote IP addresses. I receive
no more than a few of each and they don't line up with particular
networks. Remote ports are heavily 80, 443, 22, 25, etc. but a
smattering of less common ports too. I'm not seeing any RSTs at all
nor any port-unreachables. Lots of syn/acks and a few time exceeded
and host unreachables. I don't know what to make of that.


On Sat, Mar 14, 2020 at 1:46 AM Andrew Smith
 wrote:

Look inside the ICMP Unreachable backscatter at the truncated original packet 
that caused the unreachable message.

Clever! I wouldn't have thought of that. Unfortunately as in the
example above, the TTLs in the packets encapsulated in ICMP are not
especially close to one of the common boundaries.

Regards,
Bill Herrin

--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: backtracking forged packets?

[Jean | ddostest.me via NANOG]

Hi Bill,

can you post some forged packets please? You can send them offlist if 
you prefer.


It seems to be similar to what Octopus experience few weeks ago on this 
list.


Thanks

Jean St-Laurent | CISSP #634103

Re: TCP-AMP DDoS Attack - Fake abuse reports problem

[Jean | ddostest.me via NANOG]

It doesn't sound to be a real amplification.. If it is, can anyone 
provide the amplification factor? 1x?


It sounds more like a TCP spoofing.

Jean

On 2020-02-20 18:22, Töma Gavrichenkov wrote:

Peace,

On Fri, Feb 21, 2020, 1:57 AM Filip Hruska > wrote:


[..] OVH has been offering DDOS protection capable of soaking up
hundreds of gigabits+ per second as a standard with all their
services for a long time

They only do it for common trivial vectors like UDP-based 
amplification — and other types easily handleable through flowspec.


Which is honestly not their fault because they try to keep their costs 
down.  (Other means to keep the costs down may be of concern of Ronald 
G. though, but that's a different story.)


However, TCP amplification is not of that sort.

--
Töma

Re: CISCO 0-day exploits

[Jean | ddostest.me via NANOG]

I remember a Cisco device with an ACL that was leaking. It was a 20 
lines ACL with few lines to drop some packets based on UDP ports.


When under heavy stress, nearly line rate, we would see some of these 
packets going through the ACL.


I said to my peers that the ACL was leaking. They didn't believe me so I 
showed them the netflows.


We were very surprised to see that. We thought that drop means drop.

On 2020-02-10 08:40, Saku Ytti wrote:

On Mon, 10 Feb 2020 at 13:52, Jean | ddostest.me via NANOG
 wrote:


I really thought that more Cisco devices were deployed among NANOG.

I guess that these devices are not used anymore or maybe that I
understood wrong the severity of this CVE.

Network devices are incredibly fragile and mostly work because no one
is motivated to bring the infrastructure down. Getting any arbitrary
vendor down if you have access to it on L2 is usually so easy you
accidentally find ways to do it.
There are various L3 packet of deaths where existing infra can be
crashed with single packet, almost everyone has no or ridiculously
broken iACL and control-plane protection, yet business does not seem
to suffer from it.

Probably lower availability if you do upgrade your devices just
because there is a known issue, due to new production affecting
issues.

Re: CISCO 0-day exploits

[Jean | ddostest.me via NANOG]

I really thought that more Cisco devices were deployed among NANOG.

I guess that these devices are not used anymore or maybe that I 
understood wrong the severity of this CVE.


Happy NANOG #78

Cheers

Jean

On 2020-02-07 09:21, Jean | ddostest.me via NANOG wrote:

CDPwn: 5 new zero-day Cisco exploits

https://www.armis.com/cdpwn/

What's the impact on your network? Everything is under control?

Jean

CISCO 0-day exploits

[Jean | ddostest.me via NANOG]

CDPwn: 5 new zero-day Cisco exploits

https://www.armis.com/cdpwn/

What's the impact on your network? Everything is under control?

Jean

Re: Jenkins amplification

[Jean | ddostest.me via NANOG]

https://en.wikipedia.org/wiki/PfSense

In November 2017, a World Intellectual Property Organization 
 
panel found that Netgate, the copyright holder of pfSense, had been 
using the domain opnsense.com in bad faith to discredit OPNsense 
, a competing open source 
firewall forked from pfSense. It compelled Netgate to transfer the 
domain to Deciso, the developer of OPNsense.


I was happy with pfsense too, until Netgate bought the copyrights.


On 2020-02-03 15:57, Ryan Hamel wrote:

Jean,

Do you have facts to support this claim?

Signed,

A happy pfSense user.


On Mon, Feb 3, 2020, 12:42 PM Jean | ddostest.me  
via NANOG mailto:nanog@nanog.org>> wrote:


Netgate bought Pfsense and they already started to destroy it.

You should consider to switch to Opnsense.

On 2020-02-03 14:34, Matt Harris wrote:
> fSense on a VM with relatively minimal resources running your VPNs
> works very well

Re: Jenkins amplification

[Jean | ddostest.me via NANOG]

Netgate bought Pfsense and they already started to destroy it.

You should consider to switch to Opnsense.

On 2020-02-03 14:34, Matt Harris wrote:
fSense on a VM with relatively minimal resources running your VPNs 
works very well 

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Jean | ddostest.me via NANOG]

I'm a bit confused as I thought it was the other way around.

No big deal though. So these SYN don't have options which is not normal 
today. It was in the previous millenium. You should see more options.


What you can do is filter SYN based on packet length. 54 bytes is your 
signature here. The hacker is using hping3 or some basic rudimentary tools.


Cheers

Jean

On 2020-01-28 16:41, Octolus Development wrote:

Yes, my server would then respond with RST.

Screenshot: https://i.imgur.com/ZVti2yY.png

We've blocked outgoing RST, 136.244.67.19 was our test server.

But even if the ip is not even exposed to the internet, services will 
blacklist us. Even if we don't respond, and block every request from 
the internet incoming & outgoing.


On 28.01.2020 22:36:18, "Jean | ddostest.me via NANOG" 
 wrote:


But you do receive the SYN/ACK?

The way to open a TCP socket is the 3 way handshake. Sorry to write 
that here... I feel it's useless.


1. SYN

2. SYN/ACK

3. ACK

Step 1: So hackers spoof the original SYN with your source IP of your 
network.


Step 2: You should then receive those SYN/ACK packets with your 
network as the dst ip and SONY as the src ip. Can you catch a few and 
post the TCP flags that you see please? (This is step 2)


You don't need sony or imperva for that. Just a sniffer at the right 
place in your network. You won't block anything, but we should see 
something  very interesting that will help you fix this.


If it is happening like you  are describing, you should see those 
packets and you should be able to capture them.


No worries if you can't.

Jean

On 2020-01-28 11:31, Octolus Development wrote:

I have tried numerous of times to reach out to Imperva.

Imperva said Sony have to contact them & said they cannot help me 
because I am not a customer of theirs.
Something Sony will not do. Sony simply stopped responding my emails 
after some time.


But yes you are right.

My IP's are being spoofed, spoofing SYN requests to hundreds of 
thousands of web servers. Which then results in a blacklist, that 
Imperva uses.. which prevents me and my clients from accessing 
Sony's services.. because they use Imperva.


On 28.01.2020 17:29:12, Tom Beecher  wrote:

Trying to summarize here, this convo has been a bit disjointed.

Is this an accurate summary?

- The malicious traffic with spoofed sources is targeting multiple 
different destinations.
- The aggregate of all those flows is causing Impervia to flag your 
IP range as a bad actor.
- Sony uses Impervia blacklists, and since Impervia has flagged 
your space as bad, Sony is blocking you.


If that is true, my advice would be to go right to Impervia. 
Explain the situation, and ask for their assistance in identifying 
and or/reaching out to the networks that they are detecting this 
spoofed traffic coming from. The backscatter, as Jared said 
earlier, could probably help you a bit too, but Impervia should be 
willing to assist. It's in their best interests to not have false 
positives, but who knows.


On Tue, Jan 28, 2020 at 6:17 AM Octolus Development 
mailto:ad...@octolus.net>> wrote:


The problem is that they are spoofing our IP, to millions of
IP's running port 80.
Making upstream providers filter it is quite difficult, i don't
know all the upstream providers are used.

The main problem is honestly services that reports SYN_RECV as
Port Flood, but there isn't much one can do about misconfigured
firewalls.I am sure there is a decent amount of honeypots on
the internet acting the same way, resulting us (the victims of
the attack) getting blacklisted for 'sending' attacks.


On 28.01.2020 05:50:14, "Dobbins, Roland"
mailto:roland.dobb...@netscout.com>> wrote:




On Jan 28, 2020, at 11:40, Dobbins, Roland
mailto:roland.dobb...@netscout.com>> wrote:

And even if his network weren't on the receiving end of a
reflection/amplification attack, OP could still see
backscatter, as Jared indicated.


In point of fact, if the traffic was low-volume, this might in
fact be what he was seeing.



Roland Dobbins mailto:roland.dobb...@netscout.com>>

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Jean | ddostest.me via NANOG]

But you do receive the SYN/ACK?

The way to open a TCP socket is the 3 way handshake. Sorry to write that 
here... I feel it's useless.


1. SYN

2. SYN/ACK

3. ACK

Step 1: So hackers spoof the original SYN with your source IP of your 
network.


Step 2: You should then receive those SYN/ACK packets with your network 
as the dst ip and SONY as the src ip. Can you catch a few and post the 
TCP flags that you see please? (This is step 2)


You don't need sony or imperva for that. Just a sniffer at the right 
place in your network. You won't block anything, but we should see 
something  very interesting that will help you fix this.


If it is happening like you  are describing, you should see those 
packets and you should be able to capture them.


No worries if you can't.

Jean

On 2020-01-28 11:31, Octolus Development wrote:

I have tried numerous of times to reach out to Imperva.

Imperva said Sony have to contact them & said they cannot help me 
because I am not a customer of theirs.
Something Sony will not do. Sony simply stopped responding my emails 
after some time.


But yes you are right.

My IP's are being spoofed, spoofing SYN requests to hundreds of 
thousands of web servers. Which then results in a blacklist, that 
Imperva uses.. which prevents me and my clients from accessing Sony's 
services.. because they use Imperva.


On 28.01.2020 17:29:12, Tom Beecher  wrote:

Trying to summarize here, this convo has been a bit disjointed.

Is this an accurate summary?

- The malicious traffic with spoofed sources is targeting multiple 
different destinations.
- The aggregate of all those flows is causing Impervia to flag your 
IP range as a bad actor.
- Sony uses Impervia blacklists, and since Impervia has flagged your 
space as bad, Sony is blocking you.


If that is true, my advice would be to go right to Impervia. Explain 
the situation, and ask for their assistance in identifying and 
or/reaching out to the networks that they are detecting this spoofed 
traffic coming from. The backscatter, as Jared said earlier, could 
probably help you a bit too, but Impervia should be willing to 
assist. It's in their best interests to not have false positives, but 
who knows.


On Tue, Jan 28, 2020 at 6:17 AM Octolus Development 
mailto:ad...@octolus.net>> wrote:


The problem is that they are spoofing our IP, to millions of IP's
running port 80.
Making upstream providers filter it is quite difficult, i don't
know all the upstream providers are used.

The main problem is honestly services that reports SYN_RECV as
Port Flood, but there isn't much one can do about misconfigured
firewalls.I am sure there is a decent amount of honeypots on the
internet acting the same way, resulting us (the victims of the
attack) getting blacklisted for 'sending' attacks.


On 28.01.2020 05:50:14, "Dobbins, Roland"
mailto:roland.dobb...@netscout.com>> wrote:




On Jan 28, 2020, at 11:40, Dobbins, Roland
mailto:roland.dobb...@netscout.com>> wrote:

And even if his network weren't on the receiving end of a
reflection/amplification attack, OP could still see
backscatter, as Jared indicated.


In point of fact, if the traffic was low-volume, this might in
fact be what he was seeing.



Roland Dobbins mailto:roland.dobb...@netscout.com>>

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[Jean | ddostest.me via NANOG]

Maybe we're looking at the wrong place when dealing with TCP amp. I 
believe there is a much easier way to solve this.


@OP: can you post the tcp flags of the SYN/CK you are receiving from Sony?

Thanks

Jean

On 2020-01-27 20:49, Damian Menscher via NANOG wrote:
On Mon, Jan 27, 2020 at 5:43 PM Töma Gavrichenkov > wrote:


On Tue, Jan 28, 2020, 4:32 AM Damian Menscher mailto:dam...@google.com>> wrote:

On Mon, Jan 27, 2020 at 5:10 PM Töma Gavrichenkov
mailto:xima...@gmail.com>> wrote:

If this endpoint doesn't connect to anything outside of
their network, then yes.
If it does though, the design of the filter might become
more complicated.


Not really... just requires sorting by volume.  Turns out most
legitimate hosts don't send high-volume syn packets. ;)


This is a good *detection* technique, but you cannot filter by
volume in transit if the set of destinations is large (and random)
enough, and you don't have a time machine.  Not sure if this is
the case but might as well be.


They don't need to filter by destination.  Once a problem customer has 
been identified, they can apply an ACL restricting them to only 
originate IPs they own.  This was all covered in my talk at NANOG last 
year: 
https://pc.nanog.org/static/published/meetings//NANOG76/daily/day_2.html#talk_1976


As for the detection of the real source, everything is technically
possible but you need certain bargaining power which a
medium-sized (at best) VPN service probably doesn't have.


True, but there are ways around that, including public shaming (here), 
or involving law enforcement.


Damian

Re: DDoS Mitigation Survey

[Jean | ddostest.me via NANOG]

Exactly,

so one of the best option to fight DDoS is not available through public 
information.


@Lumin: You should start your investigation with uRPF loose.

Best regards,

Jean

On 2020-01-20 11:31, Dobbins, Roland wrote:

On 20 Jan 2020, at 22:49, Jean | ddostest.me wrote:


uRPF loose or strict.

Either.


Which ISP supports it?

Some operators use it themselves.  I don't know of any who allow
customer-triggered S/RTBH; several offer customer-triggered D/RTBH.


Roland Dobbins 

Re: DDoS Mitigation Survey

[Jean | ddostest.me via NANOG]

uRPF loose or strict.

Which ISP supports it?

So far, I found none through public information.


On 2020-01-20 10:38, Dobbins, Roland wrote:

On 20 Jan 2020, at 19:59, Jean | ddostest.me via NANOG wrote:


Where can we find public information on how to use S/RTBH

This .pdf preso on mitigation techniques describes how it works:

<https://app.box.com/s/xznjloitly2apixr5xge>


Roland Dobbins 

Re: DDoS Mitigation Survey

[Jean | ddostest.me via NANOG]

Where can we find public information on how to use S/RTBH

and which providers support it.

Thanks
Jean

On 2020-01-14 17:31, Dobbins, Roland wrote:

There are literally decades of information on these topics available
publicly.  Router and switch ACLs (both static and dynamically-updated
via flow spec), D/RTBH, S/RTBH

Re: DDoS attack

[Jean | ddostest.me via NANOG]

On which UDP port?

On 2019-12-09 15:07, ahmed.dala...@hrins.net wrote:

Dear All,

My network is being flooded with UDP packets, Denial of Service attack, soucing 
from Cloud flare and Google IP Addresses, with 200-300 mbps minimum traffic, 
the destination in my network are IP prefixes that is currnetly not used but 
still getting traffic with high volume.
The traffic is being generated with high intervals between 10-30 Minutes for 
each time, maxing to 800 mbps
When reached out cloudflare support, they mentioned that there services are 
running on Nat so they can’t pin out which server is attacking based on ip 
address alone, as a single IP has more than 5000 server behind it, providing 1 
source IP and UDP source port, didn’t help either
Any suggestions?

Regards,
Ahmed Dala Ali

Re: Viability of GNS3 network simulation for testing features/configurations.

[Jean | ddostest.me via NANOG]

I heard good stuff about Cisco Virl. It's like an ESX for network devices.


On 2019-10-16 15:23, Jason Kuehl wrote:
I use the server version of GNS and I love it.  I just need to VPN 
into my DC and use my client to connect to GNS.


On Wed, Oct 16, 2019 at 2:22 PM Mike Bolitho > wrote:


EVE-NG is also really good. Just an FYI, GNS3 went through a major
refresh about 18 months ago or so and it's so much better now.
Either way, you can't go wrong with GNS3 or EVE-NG.

- Mike Bolitho


On Wed, Oct 16, 2019 at 11:18 AM Aaron Gould mailto:aar...@gvtc.com>> wrote:

Oh, forgot the links…

http://www.eve-ng.net/

http://www.eve-ng.net/documentation/howto-s

*From:*NANOG [mailto:nanog-boun...@nanog.org
] *On Behalf Of *Aaron Gould
*Sent:* Wednesday, October 16, 2019 1:14 PM
*To:* 'Mike Bolitho'; 'Tom Beecher'; 'Ryland Kremeier'
*Cc:* nanog@nanog.org 
*Subject:* RE: Viability of GNS3 network simulation for
testing features/configurations.

I’ve used GNS3 some years ago for a lot of simulation and
testing.  But, I’m blown away at how much more I like EVE-NG
(emulated virtual environment next-gen)

I use the community free version… lots of vendor OS support…
of which, I’ve actually work with the following….

-XRv

-IOS virtual

-vMX

-vSRX

-vQFX

…check your in-box for a screen shot of my current environment.

-Aaron

*From:*NANOG [mailto:nanog-boun...@nanog.org
] *On Behalf Of *Mike Bolitho
*Sent:* Wednesday, October 16, 2019 12:02 PM
*To:* Tom Beecher
*Cc:* mailto:nanog@nanog.org>>
*Subject:* Re: Viability of GNS3 network simulation for
testing features/configurations.

Totally agree with Tom here. It's going to work really well
for most things. But if you're testing code for bugs you NEED
to do it on the same hardware you have in your environment in
an actual lab.


- Mike Bolitho

On Wed, Oct 16, 2019 at 9:56 AM Tom Beecher
 wrote:

GNS3 can do a heck of a lot, and the price is definitely
right.

I have used it extensively for initial fleshing out of
designs or ideas, protocol nerding, automation interaction
testing, etc. There certainly other tools out there, but
being able to visually draw a topology out, connect the
dots, and have an environment to test in about 10 minutes
is very nice. There is an API you can hook into to do some
of that for you if you are so inclined, but that would
depend on your use case and resources. For how I've used
it, never been required.

Some of the VMs from vendors can be pretty CPU and/or RAM
intensive, so I've had the best experience running them
all on a dedicated server, not locally. Again, use case
dependent. For code testing I would always run the test
set on hardware as well for likely obvious reasons.

If you really get into the weeds with it you can do quite
a lot.

On Wed, Oct 16, 2019 at 11:52 AM Ryland Kremeier
mailto:rkreme...@barryelectric.com>> wrote:

Hello,

I’m currently in the process of setting up a near
identical network to our own in GNS3 for testing
purposes. Has anyone here tried this before to any
success? We need to buy the Cisco IOSv image to
continue with the sim so I figured I would inquire
here first before diving in.

All info is appreciated,

-- 


Ryland Kremeier



--
Sincerely,

Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com 

Re: Any Gmail Admins on here?

[Jean | ddostest.me via NANOG]

Expired certificate, confirmation email delivered in SPAM.

I agree that it looks phishy even if it's probably not.

When you read the email In gmail, you can click on the 3 little dots, 
which will expand a menu and then on "Show original"


You should see 3 important email attributes for helping providers in 
flagging SPAM, which are SPF, DKIM and DMARC.


If you don't see all of the 3, there is a big chance that gmail will 
flag as SPAM.


SPF: 	PASS with IP 2600::25 Learn more 

DKIM: 	'PASS' with domain example.com Learn more 

DMARC: 	'PASS' Learn more 



Does the email have all of the 3 or only some or none?

Jean


On 10/27/18 11:38 AM, Jeremy Parr wrote:
Not only that, but I just tried signing up, and the confirmation email 
was marked as spam by GMail. Does not inspire confidence.


On Thu, Oct 25, 2018 at 1:26 PM Harald Koch > wrote:


chilli.nosignal.org  has an SSL
certificate that expired in *July*.

-- 
Harald



On Thu, 25 Oct 2018 at 12:48, Mike Hammett mailto:na...@ics-il.net>> wrote:

https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



-
Mike Hammett
Intelligent Computing Solutions 


Midwest Internet Exchange 


The Brothers WISP 



*From: *"Art Plato" mailto:apl...@coldwater.org>>
*To: *"nanog" mailto:nanog@nanog.org>>
*Sent: *Thursday, October 25, 2018 11:39:36 AM
*Subject: *Any Gmail Admins on here?

I apologize for putting this out in this forum but I have
attempted to reach Google/Gmail for several weeks with no
response. Their servers have flagged my domain with bad
reputation even thought he stats say no spam has been sent
from my domain for the past several months that I can see.
Please PM me if you are out there.

Thanks,
Art Plato

Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap

[Jean | ddostest.me via NANOG]

From an Apple device point of view, ipv6 should be faster than ipv4 
where both are available.


Because, Apple adds a 25 ms artifical penalty to ipv4 dns resolution.

https://ma.ttias.be/apple-favours-ipv6-gives-ipv4-a-25ms-penalty/

So if you test facebook from a Mac/iPhone/iPad, it will definitely loads 
faster over ipv6



On 06/19/2018 08:32 PM, lobna gouda wrote:

Although  the FB link is vague but argument itself is true. We  just became 
more intelligent in deploying IPV6.  The same measurement if was done in less  
than a decade  for example would show that ipv4 is faster.  The dual stack 
implementation and the slowness introduced by Teredo Tunneling  were the main 
reasons and  now we are getting smarter having it deprecating

https://labs.ripe.net/Members/gih/examining-ipv6-performance

   https://tools.ietf.org/html/rfc6555

https://tools.ietf.org/html/rfc7526
Things change, Ipv6  response is showing better has IPV4 is having more TCP 
re-transmission which the culprit is still not known ( need more analysis)  but 
fingers are pointing to the exhaustion of the ipv4 address so basically  CGN , 
load-balancers and address sharing.  Although  we can not eliminate peering 
links and Firewalls. Yet if we have exactly the same topology  and traffic 
crossing the links et Firewalls locations/policies. Analysis didnot confirm why 
it would have rather more harm on ipv4 than 6

  Brgds,

LG



From: NANOG  on behalf of Lee Howard 

Sent: Wednesday, June 13, 2018 7:46 AM
To: nanog@nanog.org
Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap



On 06/11/2018 05:16 PM, Scott Weeks wrote:

--- cb.li...@gmail.com wrote:
From: Ca By 


Meanwhile, FB reports that 75% of mobiles in the USA
reach them via ipv6

And Akaimai reports 80% of mobiles

And they both report ipv6 is faster / better.


Let me grab a few more for you:

https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html
Preparing for IPv6-only mobile networks: Why and How - The 
...
blogs.akamai.com
Apple's upcoming App Store submission requirement around supporting IPv6-only 
environments (announced last year at WWDC and being enforced starting June 1) 
has been getting plenty of recent coverage. iOS application developers already 
need to make sure their applications work in...





https://blogs.akamai.com/2016/10/ipv6-at-akamai-edge-2016.html

https://www.theregister.co.uk/2016/07/28/ipv6_now_faster_a_fifth_of_the_time
which cites an academic paper
http://dl.acm.org/citation.cfm?doid=2959424.2959429 by Vaibhav Bajpai
and Jürgen Schönwälder

https://www.linkedin.com/pulse/ipv6-measurements-zaid-ali-kahn/

https://community.infoblox.com/t5/IPv6-CoE-Blog/Can-IPv6-Rally-Be-Faster-than-IPv4-Part-1/ba-p/6419


https://www.nanog.org/meetings/abstract?id=2281


I'd sure like to see how they came up with these
numbers in a technically oriented paper.

Most of the above links explain how they got the numbers.
Facebook, in particular, did A/B testing using Mobile Proxygen, which is
to say that they configured their mobile app to report performance over
both IPv4 and IPv6 from the same handset at the same time.
Others, including APNIC's https://stats.labs.apnic.net/v6perf have a
browser fetch two objects with unique URLs, one from an IPv4-only server
and one from an IPv6-only server, and compare them.




   There
should be no difference, except for no CGN or Happy
Eyeballs working better or something similar.  Am I
missing something?  Same routers; same links; same
RTTs; same interrupt times on servers; same etc, etc
for both protocols.

  From time to time somebody says, "Okay, maybe it works in practice, but
does it work in *theory*?"

Busy engineers hardly ever investigate things going inexplicably right.

My hypothesis is that the observed difference in performance relates to
how mobile networks deploy their transition mechanisms. Those with a
dual-stack APN take a native path for IPv6, while using a CGN path for
IPv4, which, combined with the Happy Eyeballs head start, might add
501microseconds, which is a ms, which is 15% of 7ms. Those with an
IPv6-only APN use a native path for IPv6, while using either a NAT64 for
IPv4 (identical performance to CGN) or 464xlat, which requires
translation both in the handset and the NAT64; handsets may not be
optimized for header translation.

However, I have a dozen other hypotheses, and the few experiments I've
been able to run have not confirmed any hypothesis. For instance, when
one protocol is faster than another on a landline network, hop count is
not a correlation (therefore, shorter paths, traffic engineering, etc.,
are not involved).

Lee


Hmm...  Faster and better?

The links seem to be an IPv6 cheerleader write up.
I looked at the URLs and the URLs one pointed to and
pulled out everything 

Re: Attacks on BGP Routing Ranges

[Jean | ddostest.me via NANOG]

Maybe we are missing a key item here.

Ryan, is the attack on the BGP peering range killing your router or is 
it an attack saturating the link?


Do you have some netflow samples of one of these attacks or any kind of 
hints of what happened?


Jean St-Laurent



On 04/18/2018 11:01 PM, Roland Dobbins wrote:

On 18 Apr 2018, at 18:03, Ryan Hamel wrote:

 Could you explain how this can resolve my issue? I am not sure how 
this would work.


You should have iACLs and GTSM enabled, as noted previously. 

Re: NG Firewalls & IPv6

[Jean | ddostest.me via NANOG]

If by NextGen you meant performance, then I recommend to have a look at 
kipfw over Netmap driver on a FreeBSD 11 box. You buy a couple of 
Chelsio 40 Gbps or 100 Gbps NIC and you are in business.


It was mentioned here in NANOG couple of years ago. Very good stuff, but 
you will need to invest a bit of time in writing your own scripts.


It's a kind of bridging firewall though, so you can't route through it IIRC.

If by NextGen you meant features riched, then don't go this way. ;)

Jean

On 04/03/2018 06:16 AM, Saku Ytti wrote:

Done Checkpoint, Netscreen, SRX , iptables, nftables IPv6 FW all with
dynamic routing, but only under extreme duress, like I'm sure everyone
who is forced to touch stateful firewalls. Send help.

Seems to me this has mostly worked for over decade, worked in context
where stateful FW can be said to work at all. Of course like in every
other context, IPv6 is second class citizen, so you're going to find
more bugs, as less people are using the feature, there are less people
doing bug scrubbing and fewer people bridging feature gaps. This isn't
going to go away any time soon.

On 3 April 2018 at 03:28, David Hubbard  wrote:

I’ve been doing dual stack through Fortinet products for many years without 
issue.  Well, no issue from a technical perspective.  Sometimes you have to dig 
for a bit to find the equivalent v6 CLI commands, and occasionally there’s GUI 
stuff missing that requires CLI where the v4 equivalent didn’t, but not a bad 
experience overall.  Does v6 vpn’s great too.  Haven’t delved into dynamic 
routing protocols on them so can’t speak to that.  Happy to answer questions.

David

From: NANOG  on behalf of Joe Klein 
Sent: Monday, April 2, 2018 6:58:14 PM
To: NANOG list
Subject: NG Firewalls & IPv6

All,

At security and network tradeshows over the last 15 years, I have asked
companies if their products supported "IPv6". They all claimed they did,
but were unable to verify any successful installations. Later they told me
it was on their "Roadmap" but were unable to provide an estimated year,
because it was a trade secret.

Starting this last year at BlackHat US, I again visited every product
booth, asking if their products supported dual-stack or IPv6 only
operations. Receiving only the same unsupported answers, I decided to focus
on one product category.

To the gurus of the NANOG community, What are your experiences with
installing and managing Next Generations firewalls? Do they support IPv6
only environments? Details? Stories?

If you prefer not to disparage those poor product companies, please contact
me off the list.

Thanks,

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8

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

[Jean | ddostest.me via NANOG]

I ran a full scan of the internet with zmap to find vulnerable memcached 
servers from an AWS server. AWS received an abuse report and forwarded 
it to me.


I deleted the VM and the case was close...

LOL

OVH Is not dumb. Do you know how easy it is to deploy a VM today with 
all the automated frameworks?


Jean


On 02/28/2018 06:51 AM, Rich Kulawiec wrote:

On Wed, Feb 28, 2018 at 12:29:54AM +, Filip Hruska wrote:

OVH is one of the largest server providers in the world - of course they will 
be at the top of that list.

Of course not.  The larger an operation, the greater its responsibility
to the rest of the Internet -- because the more damage it can and will do
if it's not professionally operated.  Moreover, the larger the operation
the easier abuse control is and the less tolerance any of us should have
for failure.  I don't want to hear any clueless whining from ignorant
newbies about how-oh-so-terribly-hard-it-is-with-a-billion-users.  If you
don't know how run it, or you're too lazy, cheap, and stupid to run it,
you should never have built it: you're simply not good enough.

---rsk

Re: Opensource SNMP Trap Receivers ???

[Jean | ddostest.me via NANOG]

People often brag that snmp is super easy. You soon find out that it's 
not always the case. Some vendors do it better than others.


Whataver the tool you will use, it's important to keep in mind to start 
small.


My biggest advice is to start with 1 small example. One that is needed 
for you now.


Like I want to know when 1 power supply fails. You unplug your secondary 
power supply and test. You will figure it out.


Then you add another example like fan fails. Temperature alert.

Gradually you will add more interesting stuff like bgp/ospf lost 
neighbor. Maybe some bfd traps.


Really start small and slowly add 1 or 2 traps at a time. Only add traps 
that are important.


Snmp is really powerful but you can easily get lost in all those details.

Jean

On 13/02/18 08:29 AM, Alain Hebert wrote:

     Well,

Traps:

     snmptt is not that hard once you get used to it.

     snmpttconvert takes care of most cases... Then the rest is all 
about scripting.


     We're using it on Port Up/Down & BGP Session state change.


As for an Open NMS ...  That's another story.

https://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems

     Good luck.

     PS: We're using a tweaked version of Cacti 0.8.8x with Threshold 
and adding a sFlow Weatrhermap soon, with only ~200 devices (over 5000 
ports) but all the ports are mapped, monitored for traffic, errors and 
pps,  Sites,  Peers and Customers are also documented and we're using it 
for our billing purposes (95th).


-
Alain Hebert    aheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443

On 02/13/18 08:08, K. Scott Helms wrote:

Matthew,

Sadly, open source + SNMP traps != simple.

The simplest option that I've personally used in the past is SNMPTT with
Nagios.

https://paulgporter.net/2013/09/16/nagios-snmp-traps/

http://www.snmptt.org/docs/snmptt.shtml

The main problem is that SNMP traps, like most of SNMP, aren't simple
despite the name.  Having said that it can be done especially if the gear
doesn't change too often.

Scott Helms

On Tue, Feb 13, 2018 at 7:44 AM, Matthew Huff  wrote:


We are retiring a legacy SNMP system and are looking for a simple,
opensource SNMP trap receiver/alerting system. We aren't looking for 
a full

SNMP system, just something that will receive snmp traps and email/alert
based on them.

1) Looking for something off the shelf, not a development project
2) Opensource or low cost
3) SNMP MIB compiler

Any suggestions?


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039

Re: Blockchain and Networking

[Jean | ddostest.me via NANOG]

BTC miners use asics. Big switches/routers use 100Gb asics. Some
switches have multiple 100 Gb asics and sometimes only half is use or
even less.

I guess it could be nice for some smaller telcos to generate some profit
during off peak period. I don't know how feasible and I fully understand
that the vendor warranty should be instantly void.

Also, sometimes telcos have off the shelves spare that gather dust for
years... It could be interesting to also generate few coins.

Jean

On 18-01-09 10:31 AM, Naslund, Steve wrote:
> Sure but there are lots of blockchains other than bitcoin.  A lot of real 
> smart people do not even suspect that bitcoin is a long term survivor due to 
> its long transaction times.  Which blockchains do you want to support?  150GB 
> may not seem like a lot (although a lot of my gear does not have the memory 
> to cache that) but 10 of those is beyond the memory on the vast majority of 
> network gear I am aware of.  That sure looks like a slippery slope to me.   
> Now that a lot of network switching and routers can support applications, you 
> could just host all of your apps on them just like you could do all of your 
> routing in your servers.   The question for you is what responsibilities do 
> you want to take on.   That probably depends on what business you are in.
> 
>> There is absolutely no reason that the networking equipment itself can't 
>> both operate the blockchain and keep a full copy.  It's a pretty good bet 
>> that your own routers will probably be online;  if not, you have bigger 
>> problems.
>>
>> The storage requirements aren't particularly onerous.  The entire Bitcoin 
>> blockchain is around 150GB, with several orders of magnitude more 
>> transactions (read: config changes) than you're likely to see even on a very 
>> large network.  SSDs are small >enough and reliable enough now that the 
>> physical space requirements are quite small.
> 
> Steven Naslund
> Chicago IL
> 

Spectre/Meltdown impact on network devices

[Jean | ddostest.me via NANOG]

Hello,

I'm curious to hear the impact on network devices of this new hardware
flaws that everybody talk about. Yes, the Meltdown/Spectre flaws.

I know that some Arista devices seem to use AMD chips and some say that
they might be immune to one of these vulnerability. Still, it's possible
to spawn a bash shell in these and one with limited privileges could
maybe find some BGP/Ospf/SNMP passwords. Maybe it's also possible to
leak a full config.

I understand that one need access but still it could be possible for one
to social engineer a NOC user, hijack the account with limited access
and maybe run the "exploit".

I know it's a lot of "if" and "maybe", but still I'm curious what is the
status of big networking systems? Are they vulnerable?

Thanks

Jean

Re: Suggestions for a more privacy conscious email provider

[Jean | ddostest.me via NANOG]

If you plan to use it for a small group of people, you should consider
hosting it yourself. You could set it up with SPF, dkim, dmarc, ipv6.

It could be seen as a personal challenge to achieve.

Then if you need real privacy, you will need to encrypt with public keys
like PGP or S/MIME. You can upload your public key to the public pgp key
servers. I guess that one day this thing will be very popular.

Challenge accepted?

Jean

On 17-12-02 05:20 PM, Paul Ferguson wrote:
> On Sat, Dec 2, 2017 at 1:35 PM, Michael S. Singh 
> wrote:
> 
>> I am in need of some suggestions for some privacy conscious email 
>> providers. I am currently using Migadu [...]
> 
> I use KolabNow, based in Switzerland, for a lot of personal e-mail
> communications. They are very, very privacy conscious:
> 
> --> https://kolabnow.com/feature/confidence
> 
> They are *not* free, but quite reasonable, and I am quite happy with the
> m.
> 
> - ferg
> 
> 
> 

Re: Alternatives to ISE?

[Jean | ddostest.me via NANOG]

I'm about to try this one.

https://packetfence.org/

Not sure if it covers all the features you need though, but it seems
promising. In case you give it a try, could you share your experience
please?

Thanks
Jean

On 17-12-03 09:48 AM, segs wrote:
> Forescout but if you want something simpler with SNMP authentication of
> switches and Domain Controller of authorized PCs you can have a look at
> Portnox. Done couple of deployments with Portnox.
> 
> On Sun, Dec 3, 2017 at 3:39 PM, Christopher J. Wolff 
> wrote:
> 
>> I've about reached my limit with the dumpster fire that is Cisco's
>> Identity Service Engine.  Are there any reliable alternatives that do
>> endpoint classification, central web auth, and .1x auth?
>>
>> Thanks in advance,
>> Christopher
>>

Re: Spoofer Project

[Jean | ddostest.me via NANOG]

Is it me or NANOG's AS allowing spoofing?

https://spoofer.caida.org/as.php?asn=19230

On 17-08-03 09:19 PM, Matthew Luckie wrote:
> Hi,
> 
> The CAIDA Spoofer project has been collecting and publicly sharing
> data on the deployment of source address validation since March 2016.
> We've built up a reasonably large install-base of the open-source
> client, and receive tests from 400-500 unique IPs per day.  We're
> posting reports with links to test outcomes on the spoofer website.
> In particular, we've got summary statistics for each AS at:
> 
> https://spoofer.caida.org/as_stats.php
> 
> If you know an operator for anyone on that list who has at least one
> spoofable prefix, please feel free to reach out to them and let them
> know.  I've been sending emails to abuse contacts for nearly a year
> now.  Roughly 1/5 ASes I've contacted have fixed at least one problem.
> The remediation we know about (automatically generated) is at:
> 
> https://spoofer.caida.org/remedy.php
> 
> In order to improve the notification emails, I'm also soliciting
> configuration snippets from operators who have deployed source address
> validation.  If you have deployed SAV and wouldn't mind sharing
> redacted configuration (privately is fine) including any necessary
> platform details (such as vendor and operating system) we would
> greatly appreciate it.  We will aggregate and post configuration
> snippets at https://spoofer.caida.org/
> 
> Matthew
> 

Re: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack

[Jean | ddostest.me via NANOG]

I apologize for my previous email.

After a second thought it might sound like it's a booter even though I 
want to offer something else.


I don't want the conversation shifting toward business when we talk 
about a new DDoS technique that operate at Layer 3 with amplification 
power x100. I disabled the "booter" service and will review this offline 
with my lawyer. Thanks for pointing this out.


Now back to this new DDoS technique. If it can amplify at Layer 3, it 
could potentially be use in conjunction with the already known Layer 4 
amp DDoS like dns, ntp, ssdp, snmp, etc. It doesn't need to be use in 
conjunction but it could.


Like mentioned earlier, it doesn't need spoofing so any device could be 
part of it.


Google already acknowledged through their vulnerability program that 
there is something interesting there and they are still assessing the 
risk/impact. They suggested me to start privately disclose this with 
some big players. I thought NANOG would be a good start. I guess they 
also need time and maybe partners to test and validate all this data.


Cert-CC is also aware and they are also working out something on their 
side.


I am in good faith here and time is not against us. I discover something 
new that I want to share properly and I am not here to make business.



Sincerely,
Jean St-Laurent

On 16-12-22 08:21 AM, Tom Beecher wrote:

You're claiming to be able to generate more than 10 times as much traffic
as the largest DDoS ever seen in the wild whilst 3 months into a position
at a company that sells 'self-DDoS' services for testing purposes.

In that absence of anything more than 'GUYZ THIS IS SERIOUS' , with no
technical details, you can surely understand the skepticism.


On Thu, Dec 22, 2016 at 5:45 AM, Jean | ddostest.me via NANOG <
nanog@nanog.org> wrote:


I admit that I have a lot of guts.

Not sure who said that I am a booter or that I operate a booter. I fight
booter since more than 5 years and who would be stupid enough to put his
full name with full address to a respected network operators list?
Definitely not me.

I want to help and fix things and I am not the kind of person to break
things.


Jean


On 16-12-22 03:46 AM, j.j.santa...@utwente.nl wrote:


Hi Jean,

You are either naive or have a lot of guts to offer a Booter service in
one of the most respected network operators list. Man, as long as you use
amplifiers (third party services) or botnets your “service” is illegal &
immoral.  In case you use your own infrastructure or rent a legal (cloud)
infrastructure to provide your "service" it will not pay your costs. Not at
least by the price that you offer your service: 0,  13, 100 bucks. Even if
you have a legal/moral acceptable attack infrastructure, if you throw those
big attacks that you advertise will possibly take down many others
third-parties on the way.

Sometimes you folks say that (mis)use amplifiers for “testing” purpose is
not a problem because those services are open and publicly available on the
Internet. Come on… if I leave my car open with the key inside it doesn’t
give you the right to use my car to throw into a third party company. And
if you do, it is YOUR CRIME, not mine.

I don’t need to explain why using botnets is illegal and immoral, right?

Man, it is up to you decide between cyber crime and cyber security (
https://www.europol.europa.eu/activities-services/public-aw
areness-and-prevention-guides/cyber-crime-vs-cyber-security-
what-will-you-choose). Now, we are also looking to you on
http://booterblacklist.com<http://booterblacklist.com/>. Thanks!

Cheers,

Jair Santanna




On 22 Dec 2016, at 07:51, Alexander Lyamin <l...@qrator.net<mailto:la@qrato
r.net>> wrote:

I am just trying to grasp what is similarity between  networks on the list
and why it doesn't include, say NTT or Cogent.



On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me<http://ddostest.me/>
via NANOG <
nanog@nanog.org<mailto:nanog@nanog.org>> wrote:

Hello all, I'm a first time poster here and hope to follow all rules.

I found a new way to amplify traffic that would generate really high
volume of traffic.+10Tbps

** There is no need for spoofing ** so any device in the world could
initiate a really big attack or be part of an attack.

We talk about an amplification factor x100+. This mean that a single
computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS.
Imagine what a botnet could do?

The list of affected business is huge and I would like to privately
disclose the details to the Tier1 ISP as they are highly vulnerable.

XO Comm
PSINET
Level 3
Qwest
Windstream Comm
Eearthlink
MCI Comm/Verizon Buss
Comcast Cable Comm
AT
Sprint

I know it's Christmas time and there is no rush in disclosing this but, it
could be a nice opportunity to meditate and shed some lights on this new
DDoS threat. We could start the real work in January.


If you are curious and you operate/manage one of the ne

Re: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack

[Jean | ddostest.me via NANOG]

I admit that I have a lot of guts.

Not sure who said that I am a booter or that I operate a booter. I fight 
booter since more than 5 years and who would be stupid enough to put his 
full name with full address to a respected network operators list? 
Definitely not me.


I want to help and fix things and I am not the kind of person to break 
things.



Jean

On 16-12-22 03:46 AM, j.j.santa...@utwente.nl wrote:

Hi Jean,

You are either naive or have a lot of guts to offer a Booter service in one of the most 
respected network operators list. Man, as long as you use amplifiers (third party services) 
or botnets your “service” is illegal & immoral.  In case you use your own infrastructure 
or rent a legal (cloud) infrastructure to provide your "service" it will not pay 
your costs. Not at least by the price that you offer your service: 0,  13, 100 bucks. Even if 
you have a legal/moral acceptable attack infrastructure, if you throw those big attacks that 
you advertise will possibly take down many others third-parties on the way.

Sometimes you folks say that (mis)use amplifiers for “testing” purpose is not a 
problem because those services are open and publicly available on the Internet. 
Come on… if I leave my car open with the key inside it doesn’t give you the 
right to use my car to throw into a third party company. And if you do, it is 
YOUR CRIME, not mine.

I don’t need to explain why using botnets is illegal and immoral, right?

Man, it is up to you decide between cyber crime and cyber security 
(https://www.europol.europa.eu/activities-services/public-awareness-and-prevention-guides/cyber-crime-vs-cyber-security-what-will-you-choose).
 Now, we are also looking to you on 
http://booterblacklist.com. Thanks!

Cheers,

Jair Santanna




On 22 Dec 2016, at 07:51, Alexander Lyamin 
> wrote:

I am just trying to grasp what is similarity between  networks on the list
and why it doesn't include, say NTT or Cogent.



On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me via NANOG 
<
nanog@nanog.org> wrote:

Hello all, I'm a first time poster here and hope to follow all rules.

I found a new way to amplify traffic that would generate really high
volume of traffic.+10Tbps

** There is no need for spoofing ** so any device in the world could
initiate a really big attack or be part of an attack.

We talk about an amplification factor x100+. This mean that a single
computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS.
Imagine what a botnet could do?

The list of affected business is huge and I would like to privately
disclose the details to the Tier1 ISP as they are highly vulnerable.

XO Comm
PSINET
Level 3
Qwest
Windstream Comm
Eearthlink
MCI Comm/Verizon Buss
Comcast Cable Comm
AT
Sprint

I know it's Christmas time and there is no rush in disclosing this but, it
could be a nice opportunity to meditate and shed some lights on this new
DDoS threat. We could start the real work in January.


If you are curious and you operate/manage one of the network mentioned
above, please write to me at 
tornad...@ddostest.me from your job email to
confirm the identity. I will then forward you the DDoS details.

Best regards

Jean St-Laurent
ddostest.me
365 boul. Sir-Wilfrid-Laurier #202
Beloeil, QC J3G 4T2




--

Alexander Lyamin

CEO | Qrator * Labs*

office: 8-800--LAB (522)

mob: +7-916-9086122

skype: melanor9

mailto:  l...@qrator.net

[Tier1 ISP]: Vulnerable to a new DDoS amplification attack

[Jean | ddostest.me via NANOG]

Hello all, I'm a first time poster here and hope to follow all rules.

I found a new way to amplify traffic that would generate really high 
volume of traffic.+10Tbps


** There is no need for spoofing ** so any device in the world could 
initiate a really big attack or be part of an attack.


We talk about an amplification factor x100+. This mean that a single 
computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. 
Imagine what a botnet could do?


The list of affected business is huge and I would like to privately 
disclose the details to the Tier1 ISP as they are highly vulnerable.


XO Comm
PSINET
Level 3
Qwest
Windstream Comm
Eearthlink
MCI Comm/Verizon Buss
Comcast Cable Comm
AT
Sprint

I know it's Christmas time and there is no rush in disclosing this but, 
it could be a nice opportunity to meditate and shed some lights on this 
new DDoS threat. We could start the real work in January.



If you are curious and you operate/manage one of the network mentioned 
above, please write to me at tornad...@ddostest.me from your job email 
to confirm the identity. I will then forward you the DDoS details.


Best regards

Jean St-Laurent
ddostest.me
365 boul. Sir-Wilfrid-Laurier #202
Beloeil, QC J3G 4T2