<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>I believe that Oculus blocked the RST and not the SYN/ACK.</p>
<p>It sounds the same but, it's not.</p>
<p>I see 2 options here:</p>
<p>1. Continue to be DDoS and abuse. The result is maybe they will
move on, but I doubt.<br>
</p>
<p>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.<br>
</p>
<p>You can let us know what are the results and if I was wrong, I
will publicly state that I was wrong.</p>
<p>But, make sure you do it properly. <u>Do not block the RST</u>,
you need to block the malformed SYN/ACK before they hit your open
reflectors.</p>
<p>Jean<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2020-03-15 12:05, Amir Herzberg
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHBw0M-D72R0nx57Rm_M20fJfo=Wq2j5xD8+VYrnHV1QR=51DQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">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.
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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. <br clear="all">
<div>
<div dir="ltr" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>-- <br>
<div>Amir Herzberg<br>
</div>
<div><br>
</div>
<div>Comcast professor of Security Innovations,
University of Connecticut</div>
<div><br>
Homepage: <a
href="https://sites.google.com/site/amirherzberg/home"
target="_blank" moz-do-not-send="true">https://sites.google.com/site/amirherzberg/home</a></div>
<div><br>
</div>
<div>Foundations of Cyber-Security (part I:
applied crypto, part II: network-security): </div>
<div><a
href="https://www.researchgate.net/project/Foundations-of-Cyber-Security"
target="_blank" moz-do-not-send="true">https://www.researchgate.net/project/Foundations-of-Cyber-Security</a></div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Mar 14, 2020 at 7:51
PM Damian Menscher via NANOG <<a
href="mailto:nanog@nanog.org" target="_blank"
moz-do-not-send="true">nanog@nanog.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">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:
<div><br>
<div> - the reflectors will retry the SYN-ACK (several
times), which increases your PPS load (amplifying the
attack)</div>
<div> - the providers may notice the large number of
SYN_RECV connections from your network and put you on a
blacklist</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Damian</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Mar 14, 2020 at
1:31 PM Jean | <a href="http://ddostest.me"
target="_blank" moz-do-not-send="true">ddostest.me</a>
via NANOG <<a href="mailto:nanog@nanog.org"
target="_blank" moz-do-not-send="true">nanog@nanog.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Hi Bill,</p>
<p>thanks for sharing the data. Indeed, I can't offer
you a way to backtrack the spoofed packets.</p>
<p>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.<br>
</p>
<p>Here is what I would do if I was in your situation.</p>
<p>Since these packets are spoof and malformed, I would
block all SYN/ACK based on the length.</p>
<p>Depending on your hardware, it's very easy to inspect
<u>only the SYN/ACK by length</u> if you have modern
hardware. On linux/unix, it's also very
straightforward. I'm not sure for windows though.<br>
</p>
<p>Here is the details of the analysis:</p>
<p>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.</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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. :)</p>
<p>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.<br>
</p>
<p>I'm pretty sure that it will help you as it did for
me in the past.<br>
</p>
<p>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.</p>
<p>Regards,<br>
</p>
<p>Jean St-Laurent<br>
</p>
<div>On 2020-03-14 11:46, William Herrin wrote:<br>
</div>
<blockquote type="cite">
<pre>On Sat, Mar 14, 2020 at 4:02 AM Jean | <a href="http://ddostest.me" target="_blank" moz-do-not-send="true">ddostest.me</a> via NANOG
<a href="mailto:nanog@nanog.org" target="_blank" moz-do-not-send="true"><nanog@nanog.org></a> wrote:
</pre>
<blockquote type="cite">
<pre>can you post some forged packets please? You can send them offlist if
you prefer.
</pre>
</blockquote>
<pre>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 > <a href="http://199.33.225.218" target="_blank" moz-do-not-send="true">199.33.225.218</a>: 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]
0x0000: 4500 0038 277c 0000 3701 28da 2d59 5d1a
0x0010: c721 e1da 030d 4b61 0000 0000 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
0x0000: 4500 002c 0000 4000 3606 e564 6857 4e5f
0x0010: c721 e18f 0050 21db 487d 0dcd 00b3 852b
0x0020: 6012 7210 c97a 0000 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
<a href="mailto:andrew.william.smith@gmail.com" target="_blank" moz-do-not-send="true"><andrew.william.smith@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre>Look inside the ICMP Unreachable backscatter at the truncated original packet that caused the unreachable message.
</pre>
</blockquote>
<pre>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
<a href="mailto:bill@herrin.us" target="_blank" moz-do-not-send="true">bill@herrin.us</a>
<a href="https://bill.herrin.us/" target="_blank" moz-do-not-send="true">https://bill.herrin.us/</a>
</pre>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>