Hoe TCP/IP-verbindingen werken
Transmission Control Protocol/Internet Protocol (TCP/IP) is een spiltechnologie voor moderne computernetwerken. Het is de manier waarop (een groot deel van de tijd) uw computer vaak informatie opvraagt en ontvangt via een netwerk en het internet. Het wordt geleverd met foutcontrole, hertransmissie van ontbrekende/corrupte gegevens, en verschillende andere belangrijke functies die het internet zoals wij dat kennen letterlijk betrouwbaar en functioneel maken. Maar om te begrijpen hoe het misbruikt wordt, moeten we eerst begrijpen hoe het werkt.
Om het kort te houden, zullen we niet ingaan op het volledige TCP/IP verbindingsproces. We zullen ons alleen richten op het initiële TCP three-way handshake proces, omdat dat het enige is dat relevant is voor het onderwerp van dit artikel.
Posts op een netwerk die data willen uitwisselen met TCP moeten eerst onderhandelen over een verbinding. Dit is waar de TCP three-way handshake in het spel komt. Het handshake-proces stelt beide hosts in staat de succesvolle verzending en ontvangst van netwerkcommunicatie te bevestigen, alsmede hun respectievelijke sessie op te zetten in afwachting van de uitwisseling van applicatiegegevens.
Fig. 1) TCP drievoudige handshake
In figuur 1 zien we een client die een TCP-verbinding met een server tot stand brengt. De eerste stap is dat de client een synchronisatie- of SYN-pakket verstuurt. Dit pakket heeft twee primaire rollen, de eerste is het testen van de mogelijkheid om de bron op afstand te bereiken. Als dit pakket met succes wordt doorgestuurd, vertelt het de Server ook dat een client op afstand het verbindingsonderhandelingsproces voor gegevensuitwisseling wil beginnen. De server antwoordt door een Synchronization and Acknowledgment, of SYN-ACK, pakket uit te zenden dat terug is gericht aan de client die de verbinding initieert. Het laatste deel van de drie-weg handshake is voor de cliënt om te antwoorden op de SYN-ACK met een laatste Acknowledgement, of ACK pakket. Zodra deze handshake is voltooid, is de verbinding klaar om door de applicatie te worden gebruikt voor de bidirectionele transmissie van gegevens.
De meest gebruikte methode voor het transporteren van TCP-communicatie is via Internet Protocol of IP. Dit betekent dat de TCP pakketten tussen de client en server worden gecommuniceerd via IP datagrammen, geadresseerd via IP adressen voor elk van de apparaten.
Hoe deze aanval werkt
Aanvallers bewapenen dit handshake proces door de bron IP adressen van de SYN pakketten te spoofen. Deze spoofing zorgt ervoor dat de server het SYN-ACK pakket naar het slachtoffer-IP stuurt, waarvan de server denkt dat het de sessie-initialisatie heeft aangevraagd, waardoor het als een reflector fungeert.
Fig. 2) SYN-ACK-reflectie
In figuur 2 is een zeer eenvoudige visualisatie van deze aanval te zien. Dit laat echter niet zien hoe een echt aanvalsscenario eruit ziet. De realiteit is dat TCP is ontworpen om te werken op onbetrouwbare netwerken, wat betekent dat een enkele gespoofde SYN een server kan triggeren om snel achter elkaar meerdere SYN-ACKs te sturen als hij de laatste ACK van de handshake niet ontvangt. Het aantal te verzenden SYN-ACKs en hoe snel ze te verzenden is een configureerbare metric, dus het is moeilijk om precies in te schatten hoeveel SYN-ACKs een beoogd slachtoffer kan ontvangen in verhouding tot het volume van gespoofde SYN pakketten die door de aanvallers zijn verzonden.
Lage bandbreedte vs hoge PPS
SYN-ACK aanvallen zijn niet je typische reflectie aanvallen. Een van de belangrijkste attracties van op UDP gebaseerde reflectie-aanvallen is hun versterkingsfactor, of de grootte van het pakket dat bij het slachtoffer aankomt versus de grootte van het pakket dat een aanvaller moet verzenden. In veel gevallen is de versterkingsfactor vele malen groter dan die van het oorspronkelijke verzoek. In het geval van CLDAP-reflectie, bijvoorbeeld, is het resulterende pakket ongeveer 50-70 keer zo groot als het pakket dat de aanvaller moet verzenden om de reflectie te triggeren. Versterkingsaanvallen worden vaak als volumetrisch beschouwd, meestal met het doel de netwerklinks die door de beoogde servers en toepassingen worden gebruikt, te verzadigen.
In het geval van SYN-ACK-reflecties is de grootte van het pakket dat bij het slachtoffer wordt afgeleverd, bijna even groot als het pakket dat door de aanvaller is verstuurd. We zeggen “bijna even groot” omdat het mogelijk is, en zeer waarschijnlijk, dat terwijl de aanvaller een SYN-pakket van minimale lengte verstuurt, sommige routers op het netwerk tussen de aanvaller en het slachtoffer ook het TCP-pakket kunnen wijzigen om extra verbindingsinformatie toe te voegen, zoals de Maximum Segment Size (MSS) TCP-optie, waardoor de absolute grootte van het verkeer dat door het slachtoffer wordt waargenomen, toeneemt. Deze optie is goed voor 4 bytes extra per pakket in vergelijking met wat de aanvaller heeft verstuurd.
20:56:32.296905 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xfa7c (correct), seq 1000, win 8192, urg 0, length 0
20:56:32.315637 IP (tos 0x0, ttl 124, id 4894, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6e18 (correct), seq 3609252029, ack 1001, win 60720,
options , length 0
Fig. 3) SYN-ACK 4 byte-versterking
Dit betekent niet dat deze aanval geen bedreiging vormt. Tijdens verschillende gecoördineerde aanvallen tegen Akamai-klanten werden meerdere gevallen van floods met hoge packets per seconde (PPS) met gereflecteerd SYN-ACK-verkeer waargenomen. Hoewel verkeer met een lage bandbreedte minder snel verbindingen verzadigt, kan de hoge PPS problemen veroorzaken voor netwerkapparatuur die probeert de stortvloed aan SYN-ACKS die over netwerken raast te verwerken en te routeren.
Wat een aanvaller wel en niet kan controleren
SYN-ACK aanvallers zijn afhankelijk van de TCP-configuraties van hun reflectors en hoe deze hun TCP-verbindingen afhandelen. Dit betekent dat aanvallers beperkt zijn in wat ze kunnen reflecteren naar het slachtoffer. Onderzoekers bij Akamai hebben tijd besteed aan het testen tegen verschillende TCP enabled services op machines over het Internet om te zien welke combinatie van TCP flags & opties zou kunnen resulteren in de meest impactvolle aanvalsscenario’s. We zullen enkele aanvalsscenario’s behandelen, hoe ze verschillen en hoe aanvallers SYN-ACK aanvallen in de toekomst kunnen gebruiken.
TCP opties en opgevulde SYN-ACKS
Aanvallers hebben geen controle over de inhoud van een SYN-ACK pakket. Hoewel we al jaren opgevulde SYN floods zien, is het idee van een opgevuld SYN-ACK niet iets wat we verwachten. In de echte wereld, toen SYN-ACK aanvallen werden gelanceerd, hadden pakketten die aankwamen op de netwerken van de slachtoffers een voorspelbare lengte van 44 bytes. Zoals eerder besproken, vertelt dit ons dat de aanvallers hoogstwaarschijnlijk optieloze SYN pakketten van 40 bytes naar buiten duwden, waarbij de MSS opties hoogstwaarschijnlijk ingesteld werden door netwerkapparatuur op het pad in transit. Dit resulteert in een kleine versterkingsfactor, maar we wilden testen hoe groot we SYN-ACKs van echte servers konden krijgen.
Het testen werd uitgevoerd met verschillende variaties van TCP opties. Het doel van het testen was om de opties te identificeren die betrouwbaar gebruikt konden worden en resulteren in een grotere SYN-ACK respons van willekeurig gekozen servers op het Internet. De opties die door een aanvaller kunnen worden gebruikt en resulteren in grotere SYN-ACKs zijn Maximum Segment Size (MSS), Timestamp (TS), Selective ACK (SAckOK), Window Scale (WScale), & TCP Fast Open (TFO) cookies.
Alleen al door het gebruik van geldige opties kan een aanvaller ruwweg 62% meer bandbreedte verbruiken dan met een minimaal SYN-pakket (72 bytes vs. 44 bytes). Het gebruik van deze opties, headers verminderen de amplificatie ratio (10% amplificatie wordt 6-7%); het is echter nog steeds mogelijk om amplificatie te bereiken door simpelweg de MSS optie weg te laten, aangezien deze in transit zal worden gezet, ongeacht of de aanvaller deze wel of niet stuurt.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options
, length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win
60192, options , length 0
Fig. 4) SYN-ACK padding met TFO
Tijdens het testen was het mogelijk om de TS, SAckOK, WSCale, & TFO TCP-opties (en NOP padding) te gebruiken om een SYN-pakket van 68 bytes te verzenden dat resulteerde in een SYN-ACK-antwoord van 72 bytes dat werd afgeleverd bij het slachtoffer, zoals te zien is in figuur 4. Als een host TFO niet ondersteunt, kan een aanvaller nog steeds een 56 byte SYN pakket pushen dat resulteert in een 60 byte SYN-ACK dat naar het slachtoffer netwerk wordt gerouteerd, zoals hieronder te zien is in figuur 5.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options
, length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192,
options , length 0
Fig. 5) SYN-ACK opvulling minus TFO
SYN-ACK versterking
Een minieme hoeveelheid versterking is mogelijk met SYN-ACK aanvallen, maar het is mogelijk om deze versterkingsfactor te vergroten door zich te richten op IP-ruimte die is toegewezen maar onbezet is (wat betekent dat het IP gerouteerd kan worden, maar dat er momenteel geen machine is ingezet en/of netwerkverkeer afhandelt). Dit scenario staat aanvallers toe om volledig gebruik te maken van TCP hertransmissie inspanningen, wat op zijn beurt de versterkingsfactoren en bandbreedte consumptie verhoogt.
Wanneer een normale machine een out-of-state SYN-ACK ontvangt van een reflector, zal het antwoorden met een RST pakket zoals hieronder getoond in Figuur 6. Dit RST pakket zal door de reflector ontvangen worden, en de TCP sessie op de reflector zal gedood worden.
21:33:15.173204 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xfa7b (correct), seq 1000, win 8192, urg 0, length 0
21:33:15.191517 IP (tos 0x0, ttl 124, id 46635, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xb751 (correct), seq 1209013908, ack 1001, win
60720, options , length 0
21:33:15.191558 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 6) out of state SYN-ACK veroorzaakt een RST-reactie
Als dit SYN-ACK pakket bestemd is voor een IP-adres dat is toegewezen maar onbezet is, zal het SYN-ACK pakket worden gerouteerd (en onderweg invloed hebben op de netwerkapparatuur) maar nooit een echte machine bereiken die een RST zou uitgeven. Dit gebrek aan een RST pakket zorgt ervoor dat de reflector aanneemt dat de aflevering van de SYN-ACK mislukt is en opnieuw begint te zenden.
Bij het testen ligt het aantal pogingen tot hertransmissie typisch tussen de 5 en 7 SYN-ACK pakketten die naar het slachtoffer worden gestuurd voor elke verstuurde SYN. Als we aannemen dat een aanvaller een SYN van 40 bytes verstuurt, kunnen we 5-7 SYN-ACK-pakketten van 44 bytes verwachten die het netwerk van het slachtoffer doorkruisen. In een worst case scenario van 7 ontvangen pakketten, resulteert dit in een 40 byte verzoek dat 308 bytes aan pakketten genereert die aankomen aan de grenzen van het slachtoffer, een versterkingsfactor van 770%. Door gebruik te maken van TCP-optieheaders om grotere SYN-ACK’s te genereren, zou een aanvaller deze aantallen naar 56 bytes kunnen duwen, wat resulteert in 420 bytes aan gereflecteerd verkeer, een versterkingsfactor van 750%.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options , length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:24.965713 IP (tos 0x0, ttl 124, id 46784, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfd96 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:26.965689 IP (tos 0x0, ttl 124, id 47738, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf5c6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:30.965750 IP (tos 0x0, ttl 124, id 49898, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xe626 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:38.965701 IP (tos 0x0, ttl 124, id 53757, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xc6e6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:54.965710 IP (tos 0x0, ttl 124, id 61887, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x8866 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
Fig. 7) SYN resulteert in 6 SYN-ACKS
TFO, padding en amplification
TCP Fast Open (TFO) wordt hier in meer detail besproken om enkele interessante randgevallen te behandelen die bij het testen zijn waargenomen. Met TFO-cookies is het mogelijk om grotere reacties te genereren (12 bytes extra per SYN-ACK); maar door onzorgvuldigheden in de TFO implementatie kunnen deze maatregelen de amplificatiefactoren veranderen en onder verschillende scenario’s kunnen de aanvallen met TFO wenselijker zijn.
Aanvallers die proberen gebruik te maken van reflectors met TFO, kunnen dit alleen in bepaalde omstandigheden vruchtbaar vinden. Als een aanvaller gereflecteerde SYN-ACK pakketten naar echte machines moet sturen die reageren met RST-pakketten, dan is TCP retransmission amplification in wezen zinloos omdat de reflector zal stoppen met het versturen van SYN-ACK’s als hij het RST-antwoord van de machines van het slachtoffer ontvangt.
Om dit voorstel nog minder wenselijk te maken, zullen hosts die TFO ondersteunen de 12 byte header optie voor het TFO cookie niet opnemen in aanvullende SYN-ACK pakketten na het eerste verzonden pakket. Wat dit in het kort betekent is dat amplificatie in dit scenario niet een serie van 72 byte pakketten is die het slachtoffer raken. In echte wereld testen werd waargenomen dat de eerste SYN-ACK 72 bytes zal zijn, maar de volgende 5-6 pogingen tot hertransmissie zullen deze TCP optie weglaten en resulteren in een 60 byte pakket. In dit geval resulteert een pakket van 72 bytes in een reflectie van 432 bytes; in wezen is het enige voordeel de 12 extra bytes van het allereerste pakket versus een reflectie minus de TFO cookie-optie.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options , length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:46.651887 IP (tos 0x0, ttl 124, id 51447, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6bb0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:48.651862 IP (tos 0x0, ttl 124, id 52323, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x63e0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:52.651854 IP (tos 0x0, ttl 124, id 54181, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x5440 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:00.651876 IP (tos 0x0, ttl 124, id 58527, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x3500 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:16.651862 IP (tos 0x0, ttl 124, id 2147, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf67f (correct), seq 3436032873, ack 1001, win 60192, options , length 0
Fig. 8) Weglating TFO-cookie na eerste reactie
TFO-compatibele hosts resetten hun handshake-cookiemaatregelen na ontvangst van een RST van de slachtoffermachine(s) die het doelwit is (zijn). Dit betekent dat een aanvaller die zich richt op echte machines die TFO enabled reflectors gebruiken, op betrouwbare wijze een serie SYN-ACK pakketten van 72 bytes kan laten aankomen op de eindpunten van de slachtoffers.
De versterkingsfactor is slechts 4 bytes, ervan uitgaande dat een verzoek van 68 bytes van de aanvaller resulteert in een SYN-ACK van 72 bytes die aankomt bij het slachtoffer, gevolgd door een RST pakket van het slachtoffer naar de reflector. Als dit continu gebeurt, dan zullen de TCP sessies die via de aanvaller op de reflector worden geïnitieerd altijd resulteren in een SYN-ACK pakket dat de extra bytes bevat die de TFO cookie optie vormen.
20:54:41.611605 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x8762 (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:41.629518 IP (tos 0x0, ttl 124, id 14354, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6ade (correct), seq 3714341928, ack 1001, win 60192, options , length 0
20:54:41.629548 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:42.664171 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xc1bd (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:42.682391 IP (tos 0x0, ttl 124, id 15171, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6d0a (correct), seq 3730789605, ack 1001, win 60192, options , length 0
20:54:42.682440 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:43.781512 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x7dde (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:43.800464 IP (tos 0x0, ttl 124, id 15726, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xf5fe (correct), seq 3748251272, ack 1001, win 60192, options , length 0
20:54:43.800534 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 9) TFO-cookie-inclusie na RST
Zorgen over mitigatie
Het mitigeren van een SYN-ACK-reflectie kan lastig zijn en moet zorgvuldig worden gedaan. Het is heel gemakkelijk om dit type aanval te veel te beperken en zichzelf schade toe te brengen aan echte clients en TCP-sessies in productienetwerken. Deze beïnvloede sessies zouden zich vertalen in connectiviteitsproblemen, verminderde performantie en het blokkeren van legitieme hosts/gebruikers over uw netwerken. Deze over-mitigatie maatregelen kunnen langere en meer impact hebben dan de aanval zelf.
In veel gevallen kan over-mitigatie van TCP impacting aanvallen ook onverwachte resultaten hebben voor de slachtoffers. Tijdens SYN-floods komt het bijvoorbeeld vaak voor dat, wanneer echte diensten verbindingsproblemen krijgen, een secundaire aanvalsgolf over het netwerk aanzwelt. In dergelijke gevallen is de “tweede golf” allesbehalve een gevolg van echte clients/gebruikers die zonder succes proberen legitieme verbindingen tot stand te brengen; dit vertaalt zich in een golf van hoger dan normale SYN-pakketten omdat de getroffen clients blijven proberen niet-erkende SYN-pakketten opnieuw te verzenden.
Extra mitigatie van een SYN-ACK aanval kan waarschijnlijk problemen en soortgelijke resultaten veroorzaken, vooral als mitigatie plaatsvindt op een punt in het netwerk waar echte clients legitieme uitgaande verzoeken doen.
De ECHTE oplossing voor reflectie-aanvallen
Zoals met de meeste spoofing-aanvallen is de echte oplossing niet iets waar een enkele organisatie controle over heeft. Om dit en andere problemen in verband met spoofing-mogelijkheden echt aan te pakken, moeten we naar de IETF en netwerkexploitanten kijken. De IETF heeft BCP38 gepubliceerd, waarin wordt beschreven hoe netwerkbeheerders het routeren van “spoofed” verkeer kunnen identificeren en voorkomen. Uiteindelijk is het iets dat netwerkbeheerders moeten implementeren en afdwingen als we echt willen dat dit soort spoofed/reflected aanvallen verdwijnen, of in ieder geval aanzienlijk moeilijker te orkestreren worden.
Samenvatting
Reflected SYN-ACK aanvallen zijn niet iets nieuws; ze zijn eigenlijk al zo oud als TCP zelf. Hun gebrek aan populariteit heeft meer te maken met andere UDP-gebaseerde gereflecteerde aanvallen die veel zorgwekkender en impactvoller zijn en in het algemeen een betere toolset voor aanvallers. Ze zijn geen neveneffect van een gebrekkige implementatie, ze zijn geen exploit, ze zijn een symptoom van het feit dat IP spoofing over het Internet nog steeds mogelijk is, bijna 20 jaar nadat de voorgestelde oplossing voor netwerkeigenaren en operators werd opgesteld en afgerond.
Dat gezegd hebbende, oude aanvallen kunnen nog steeds pijnlijk zijn, en gereflecteerde SYN-ACKs zijn daarop geen uitzondering. Organisaties zouden moeten overwegen om hun mogelijkheden en opties voor mitigatie te onderzoeken, aangezien netwerkapparatuur moeite kan hebben om hoge PPS-stromen van verkeer over grenzen en netwerken te verwerken.
Het is belangrijk om de reële mogelijkheid van over-mitigatie voor dit soort aanvallen te benadrukken en om ervoor te zorgen dat pogingen om dit soort aanvallen te bestrijden niet resulteren in zichzelf opgelegde onderbrekingen… een taak die veel gemakkelijker gezegd dan gedaan is.