[Technische analyse] Diepgaand en gemakkelijk te begrijpen: Introductie tot de aanval van netwerkaanvallen en verdediging

DDoS-aanvallen (Distributed Denial of Service) zijn een van de krachtigste en moeilijkste aanvallen om tegen te verdedigen, omdat het hoofddoel van DDoS-aanvallen is om te voorkomen dat een aangewezen doelwit normale diensten levert of zelfs van het internet verdwijnt.

DDoS kan eenvoudig worden onderverdeeld in drie categorieën afhankelijk van de manier waarop ze worden gestart.

De eerste categorie wint met geweldEnorme datapakketten stromen uit alle hoeken van het internet, blokkeren de toegang tot IDC, waardoor verschillende krachtige hardwareverdedigingssystemen en snelle en efficiënte noodprocessen nutteloos worden. Typische voorbeelden van dit type aanval zijn ICMP Flood en UDP Flood, die nu zeldzaam zijn.

De tweede categorie wint door slimheid, slim en onmerkbaar, kan het versturen van een pakket om de paar minuten of zelfs alleen een pakket nodig hebben ervoor zorgen dat de luxe configuratieserver niet meer reageert. Dit type aanval wordt voornamelijk gestart door kwetsbaarheden in protocollen of software te exploiteren, zoals Slowloris-aanvallen, hashbotsingsaanvallen, enzovoort, en vereist specifieke omgevingstoevalligheden.

De derde categorie is een mengeling van de bovenstaande tweeHet maakt niet alleen gebruik van de gebreken van het protocol en systeem, maar heeft ook een grote hoeveelheid verkeer, zoals de SYN Flood-aanval en de DNS Query Flood-aanval, wat de huidige gangbare aanvalsmethode is.

Dit artikel zal deze meest voorkomende en representatieve aanvalsmethoden één voor één beschrijven en hun verdedigingsopties introduceren.

SYN Flood is een van de meest klassieke DDoS-aanvallen op het internet, met het eerste optreden rond 1999, waarbij Yahoo destijds het bekendste slachtoffer was. SYN Flood-aanvallen maken gebruik van TCP triple handshake-fouten die de doelserver onresponsief en moeilijk te traceren kunnen maken tegen een kleine kosten.

Het standaard TCP drieweg-handshakeproces is als volgt:

• De client stuurt een TCP-pakket met de SYN-vlag, SYN wordt gesynchroniseerd, en het synchronisatiepakket geeft de poort aan die door de client wordt gebruikt en het initiële serienummer van de TCP-verbinding.
• Na ontvangst van het SYN-pakket van de client zal de server een SYN+ACK (d.w.z. bevestigingspakket) teruggeven, waarmee wordt aangegeven dat het verzoek van de client is geaccepteerd, en het TCP-initiële serienummer wordt automatisch met 1 toegevoegd.
• De client stuurt ook een bevestigingsbericht ACK terug naar de server, en het TCP-serienummer wordt ook toegevoegd met 1.
  

Na deze drie stappen wordt de TCP-verbinding tot stand gebracht. Om betrouwbare transmissie te bereiken, heeft het TCP-protocol enkele uitzonderingsafhandelingsmechanismen opgezet tijdens de drie handshakes. In de derde stap, als de server het laatste ACK-bevestigingspakket niet van de client ontvangt, blijft de server in de SYN_RECV-toestand, voegt het client-IP-adres toe aan de wachtlijst en verzendt het SYN+ACK-pakket opnieuw in de tweede stap. Herplaatsingen worden meestal 3-5 keer uitgevoerd, en de wachtlijst wordt één keer gepolld met intervallen van ongeveer 30 seconden om alle klanten opnieuw te proberen. Aan de andere kant, nadat de server het SYN+ACK-pakket heeft verzonden, wordt de middelen vooraf toegewezen om informatie op te slaan voor de aankomende TCP-verbinding, die wordt behouden terwijl op de herpoging. Belangrijker nog, als de serverbronnen beperkt zijn, zal de SYN_RECV toestand die behouden kan worden geen nieuwe SYN-pakketten meer accepteren na het overschrijden van de limiet, dat wil zeggen, nieuwe TCP-verbindingen worden afgewezen.

SYN Flood gebruikt de hierboven genoemde TCP-protocolinstellingen om het doel van de aanval te bereiken. Aanvallers verbergen een groot aantal IP-adressen om SYN-pakketten naar de server te sturen, en omdat de vervalste IP-adressen vrijwel onmogelijk zijn, zal bijna geen enkel apparaat een antwoord aan de server teruggeven. Daardoor heeft de server een enorme wachtlijst en probeert hij steeds opnieuw SYN+ACK-pakketten te versturen, wat veel middelen verbruikt en niet kan worden vrijgegeven. Belangrijker nog, de SYN_RECV wachtrij van de aangevallen server zit vol met kwaadaardige pakketten, nieuwe SYN-verzoeken worden niet langer geaccepteerd, en legitieme gebruikers kunnen geen drie handdrukken uitvoeren om TCP-verbindingen tot stand te brengen. Met andere woorden, de server werd door SYN Flood geweigerd.

Als je geïnteresseerd bent in SYN Flood, kun je de http://www.icylife.net/yunshu/show.php?id=367 bekijken, die ik in 2006 schreef, later verschillende wijzigingen aanbracht, bugs oploste, de agressiviteit verminderde, en die puur voor testen werd gebruikt.

Als de meest basale en kerndienst van het internet is DNS vanzelfsprekend een van de belangrijke doelwitten van DDoS-aanvallen. Het uitschakelen van een DNS-dienst kan indirect het hele bedrijf van een bedrijf of een netwerkdienst in een regio ten val brengen. Enige tijd geleden kondigde de populaire hackergroep Anonymous ook aan dat ze 13 DNS-servers op het wereldwijde internet zou aanvallen, maar uiteindelijk slaagde dat niet.

UDP-aanvallen zijn de gemakkelijkste aanvalsmethode om massaal verkeer te initiëren, en willekeurige IP-vervalsing is moeilijk te traceren. Filteren is echter eenvoudiger omdat de meeste IP's geen UDP-diensten aanbieden, dus je kunt gewoon UDP-verkeer weggooien. Daarom zijn pure UDP-verkeersaanvallen tegenwoordig relatief zeldzaam, en worden ze vervangen door DNS Query Flood-aanvallen die door het UDP-protocol worden gedragen. Simpel gezegd, DDoS-aanvallen die worden gelanceerd op het hogere protocol, hoe moeilijker het is om het te verdedigen, omdat hoe hoger het protocol, hoe meer het bedrijfsgerelateerd is en hoe complexer het verdedigingssysteem wordt.

DNS Query Flood is wanneer een aanvaller een groot aantal sockpuppet-machines manipuleert om een groot aantal domeinnaamqueryverzoeken naar het doelwit te sturen. Om ACL-gebaseerde filtering te voorkomen, moet de pakketwillekeurigheid worden verbeterd. Een gangbare praktijk is het willekeurig forgen van het bron-IP-adres, het willekeurig smeden van de bronpoort en andere parameters op de UDP-laag. Op de DNS-protocollaag wordt de query-ID willekeurig vervalst samen met de domeinnaam die opgelost moet worden. Naast het voorkomen van filtering kunnen willekeurig vervalste domeinnamen die worden opgelost ook de kans verkleinen dat ze de DNS-cache raken en zoveel mogelijk CPU-middelen van de DNS-server verbruiken.

Wat betreft de code voor DNS Query Flood, heb ik in juli 2011 een code geschreven om de serverprestaties te testen, en de link is http://www.icylife.net/yunshu/show.php?id=832. Evenzo is deze code kunstmatig minder agressief en alleen bedoeld voor testdoeleinden.

De hierboven beschreven SYN Flood en DNS Query Flood kunnen in deze fase effectief worden verdedigd, en de echte hoofdpijn voor grote fabrikanten en internetbedrijven zijn HTTP Flood-aanvallen. HTTP Flood is een aanval op een webservice op een protocol op de zevende laag. De grote schade ervan manifesteert zich vooral in drie aspecten: gemakkelijke initiatie, moeilijke filtering en verstrekkende impact.

Zowel SYN Flood als DNS Query Flood vereisen dat aanvallers een groot aantal bots met rootrechten aansturen. Het kost tijd en moeite om een groot aantal rootprivileges te verzamelen, en tijdens de aanval is de poppenmachine traag om aan te vullen vanwege het snelle verlies van middelen door de aanvaller door abnormaal verkeer dat door de beheerder wordt ontdekt, wat resulteert in een aanzienlijke vermindering van de intensiteit van de aanval en niet lang kan worden volgehouden. HTTP Flood-aanvallen zijn anders; aanvallers hoeven niet een groot aantal bots te controleren, maar gebruiken in plaats daarvan poortscanners om anonieme HTTP-proxies of SOCKS-proxies op het internet te vinden, waarmee de aanvaller HTTP-verzoeken naar het doelwit van de aanval initieert. Anonieme proxies zijn een relatief rijke bron, en het is niet moeilijk om proxies binnen enkele dagen te verkrijgen, dus aanvallen zijn gemakkelijk te starten en kunnen lang duren.

Aan de andere kant worden HTTP-flood-aanvallen gelanceerd op de HTTP-laag, die het webpaginaverzoekgedrag van normale gebruikers krachtig nabootst, wat nauw verbonden is met de websitebusiness, waardoor het voor beveiligingsleveranciers moeilijk is om een gemeenschappelijke oplossing te bieden die de gebruikerservaring niet beïnvloedt. Regels die goed werken op één plek, veranderende scenario's kunnen leiden tot veel doodslag.

Ten slotte kunnen HTTP-flood-aanvallen ernstige kettingreacties veroorzaken, niet alleen direct trage reacties van de aangevallen webfront-end, maar ook indirect de back-end Java en andere bedrijfslaaglogica en back-end databaseservices aanvallen, waardoor hun druk toeneemt en zelfs logopslagservers wordt beïnvloed.

Interessant genoeg heeft HTTP Flood ook een historische bijnaam genaamd CC-aanval. CC is een afkorting voor Challenge Collapsar, een DDoS-beschermingsapparaat van een bekend beveiligingsbedrijf in China. Afgaande op de huidige situatie wordt niet alleen Collapsar, maar alle hardware-verdedigingsapparatuur nog steeds uitgedaagd, en het risico is niet weggenomen.

Als het om aanvallen gaat, is de eerste reactie enorm verkeer en enorme pakketten. Maar er is een aanval die het tegenovergestelde doet, bekend om zijn traagheid, waardoor sommige aanvalsdoelen worden gedood zonder te weten hoe ze sterven, namelijk de slow connection-aanval, waarvan de meest representatieve Slowloris is uitgevonden door rsnake.

Het HTTP-protocol bepaalt dat HTTP-verzoeken eindigen op \r\n\r\n, wat aangeeft dat de client klaar is met verzenden en de server is begonnen met verwerken. Dus wat gebeurt er als je nooit \r\n\r\n stuurt? Slowloris gebruikt dit in zijn voordeel bij DDoS-aanvallen. De aanvaller zet de verbinding op Keep-Alive in de HTTP-verzoekheader, vraagt de webserver om de TCP-verbinding niet te laten verbreken, en stuurt vervolgens langzaam elke paar minuten een sleutel-waarde-formaat naar de server, zoals a:b\r\n, waardoor de server denkt dat de HTTP-header niet is ontvangen en wacht. Als een aanvaller multithreading of een marionet gebruikt om hetzelfde te doen, raakt de webcontainer van de server snel overweldigd door de aanvaller en accepteert geen nieuwe verzoeken meer.

Al snel begonnen er verschillende varianten van Slowloris te verschijnen. Bijvoorbeeld, de POST-methode stuurt data naar de webserver, vult een grote inhoud-lengte maar trage POST-data byte voor byte echte data-inhoud, enzovoort. Wat betreft de Slowloris-aanval, geeft rsnake ook een testcode, zie http://ha.ckers.org/slowloris/slowloris.pl.

Bovenstaande introduceert verschillende basisaanvalsmethoden, waarvan elk kan worden gebruikt om het netwerk aan te vallen en zelfs gigantische websites zoals Alibaba, Baidu en Tencent te verslaan. Maar dat is nog niet alles, verschillende niveaus van aanvallers kunnen totaal verschillende DDoS-aanvallen uitvoeren, en het gebruik ervan is hetzelfde.

Geavanceerde aanvallers gebruiken nooit één enkele vector om aan te vallen, maar combineren deze flexibel op basis van de doelomgeving. Gewone SYN Flood is eenvoudig te filteren door verkeersreinigingsapparaten via reverse detection, SYN-cookies en andere technische middelen, maar als SYN+ACK-pakketten worden gemengd in SYN Flood, zodat elk vervalst SYN-pakket een overeenkomstig vervalst clientbevestigingspakket heeft, verwijst het overeenkomstige hier naar het bron-IP-adres, bronpoort, bestemmings-IP, bestemmingspoort, TCP-venstergrootte, TTL, enzovoort, en zijn allemaal in lijn met de kenmerken van dezelfde host en dezelfde TCP-flow. De druk op de prestaties van omgekeerde detectie en SYN-cookies van stroomreinigingsapparatuur zal aanzienlijk toenemen. In feite hebben SYN-datapakketten en diverse andere vlagbits speciale aanvalseffecten, die hier niet worden geïntroduceerd. Er zijn ook unieke technieken voor DNS Query Flood.

Allereerst kan DNS worden opgesplitst in gewone DNS en geautoriseerde domein-DNS, waarbij gewone DNS wordt aangevallen, het IP-adres willekeurig vervalst moet worden en de server recursieve resolutie vereist; Bij het aanvallen van het geautoriseerde domein-DNS mag het vervalste bron-IP-adres echter niet puur willekeurig zijn, maar de DNS-adressen van ISP's wereldwijd vooraf verzameld zijn, om zo het maximale aanvalseffect te bereiken, zodat het traffic clean-apparaat in de beschamende situatie terechtkomt om een IP-blacklist toe te voegen of niet toe te voegen. Het toevoegen ervan leidt tot een groot aantal doodslagen, en als je geen zwarte lijst toevoegt, moet elk pakket worden omgekeerd geproebd, wat de prestatiedruk verhoogt.

Aan de andere kant, zoals eerder vermeld, is het om de druk van het schoonmaken van het apparaat te verhogen noodzakelijk om de gevraagde domeinnaam te randomiseren zonder de cache te raken, maar het moet worden opgemerkt dat de domeinnaam die opgelost moet worden een zekere regelmaat moet hebben in de vervalsing, zoals het vervalsen van slechts een bepaald deel van de domeinnaam en het vaststellen van een deel om door de whitelist van het reinigingsapparaat heen te breken. De reden is simpel: de servers van Tencent kunnen alleen domeinnamen van Tencent oplossen, en volledig willekeurige domeinnamen kunnen direct worden verworpen en moeten worden vastgelegd. Maar als het volledig is gerepareerd, is het makkelijk direct te laten vallen, dus moet het gesmeed worden.

Ten tweede mogen aanvallen op DNS zich niet uitsluitend richten op UDP-poorten, die volgens het DNS-protocol ook standaarddiensten zijn. In het geval van een aanval kunnen zowel UDP- als TCP-aanvallen tegelijkertijd worden uitgevoerd.

De focus van HTTP Flood is om door de cache aan de frontend heen te breken en direct de webserver zelf te bereiken via de veldinstellingen in de HTTP-header. Daarnaast is HTTP Flood ook zeer cruciaal voor de selectie van doelen, en gewone aanvallers kiezen pagina's die veel datazoekopdrachten vereisen, zoals zoekfunctie als aanvalsdoel, wat zeer correct is en zoveel mogelijk middelen van de server kan verbruiken. Maar deze aanval is gemakkelijk te herkennen door apparatuur schoon te maken via mens-machine identificatie, dus hoe los je dit probleem op? Het is heel eenvoudig: probeer pagina's te kiezen die gewone gebruikers ook via de APP benaderen, meestal verschillende web-API's. Normale gebruikers en kwaadaardig verkeer komen van de APP, en het verschil tussen mens en machine is zeer klein, waardoor het moeilijk is om basisintegratie te onderscheiden.

Elke TCP-verbinding bestaat aan de serverzijde en op zichzelf, en moet ook middelen verbruiken om de TCP-toestand te behouden, dus de verbinding kan niet te veel worden onderhouden. Als dit opgelost kan worden, zal de agressiviteit sterk toenemen, dat wil zeggen, Slowloris kan aanvallen op stateloze wijze uitvoeren, het TCP-serienummer vastleggen en het onderhoud van TCP-verbindingen op de client bevestigen door te sniffen, en de systeemkernel hoeft geen aandacht te besteden aan verschillende toestandswijzigingen van TCP, en een notebook kan tot 65.535 TCP-verbindingen genereren.

De vorige beschrijvingen zijn allemaal technische aanvalsverbeteringen. Aan de menselijke kant zijn er andere middelen. Als SYN Flood een groot aantal pakketten verstuurt en gepaard gaat met slowloris slow-verbindingen, hoeveel mensen zullen dan het geheim ontdekken? Zelfs als de server uitvalt, kunnen alleen SYN-aanvallen worden gevonden, die proberen het opruimen van de TCP-laag te versterken en het gedrag van de applicatielaag te negeren. Alle soorten aanvallen kunnen samenwerken om maximaal effect te bereiken. De keuze van de aanvalstijd is ook een belangrijk punt, zoals het kiezen van onderhoudspersoneel tijdens de lunch, wanneer onderhoudspersoneel vastzit op de weg na het verlaten van het werk of wanneer er geen signaal is op de draadloze netwerkkaart in de metro, en wanneer het doelbedrijf een grootschalig evenement organiseert en het verkeer stijgt.

Dit is een pure aanval, dus er wordt geen code of diepgaande uitleg gegeven.

De eerdere aanvalsmethoden vereisen min of meer enkele bots, zelfs HTTP Flood vereist het zoeken naar een groot aantal anonieme proxies. Als er een aanval is, hoef je alleen enkele instructies te geven, en de machine komt automatisch omhoog om deze uit te voeren, wat de perfecte oplossing is. Deze aanval is al verschenen, en dat is vanuit P2P-netwerken.

Zoals we allemaal weten, zijn P2P-gebruikers en verkeer op het internet een extreem groot aantal. Als ze allemaal naar een aangewezen plek gaan om data te downloaden en duizenden echte IP-adressen te verbinden, kan geen enkel apparaat het ondersteunen. Neem BT-download als voorbeeld: het vervalsen van torrents van populaire video's en het plaatsen daarvan in zoekmachines is genoeg om veel gebruikers en verkeer te misleiden, maar dit is slechts een eenvoudige aanval.

Geavanceerde P2P-aanvallen zijn directe spoofing van resource management-servers. De Thunder-client uploadt bijvoorbeeld de bronnen die hij vindt naar de resource management-server en stuurt deze vervolgens naar andere gebruikers die dezelfde bronnen moeten downloaden, zodat er een link wordt gepubliceerd. Door protocolomkering vervalsen aanvallers een grote hoeveelheid populaire broninformatie en verspreiden deze via het resource management center, die direct over het gehele P2P-netwerk kan worden verspreid. Wat nog angstaanjagender is, is dat deze aanval niet kan worden gestopt, zelfs niet door de aanvaller zelf, en de aanval doorgaat totdat de P2P-functionaris het probleem vindt en de server bijwerkt en de downloadgebruiker de gedownloade software opnieuw opstart.

Dat is alles wat er is bij de introductie van DDoS-aanvallen, en ik wil niet verder gaan—het is genoeg om te begrijpen dat zoveel verdediging genoeg is.

Over het algemeen kunnen DDoS-aanvallen behendig en gracieus zijn. De schoonheid van toepassing ligt in de eenheid van de geest.