Re: backtracking forged packets?

[Amir Herzberg <amir.lists () gmail com>]

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 <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 <
> 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 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<nanog () nanog org> <nanog () nanog org> 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]
> >         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<andrew.william.smith () gmail com> <andrew.william.smith () gmail com> 
> > 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 Herrinbill@herrin.ushttps://bill.herrin.us/