[Teknisk analyse] Dybdegående og letforståelig: Introduktion til angrebet på netværksangreb og forsvar

DDoS-angreb (Distributed Denial of Service) er nogle af de mest kraftfulde og sværeste angreb at forsvare sig imod, fordi hovedformålet med DDoS-angreb er at forhindre et udpeget mål i at levere normale tjenester eller endda forsvinde fra internettet.

DDoS kan enkelt opdeles i tre kategorier alt efter, hvordan de igangsættes.

Den første kategori vinder med magtMassive datapakker strømmer ind fra alle hjørner af internettet, blokerer adgangen til IDC, gør forskellige kraftfulde hardwareforsvarssystemer og hurtige og effektive nødprocesser ubrugelige. Typiske eksempler på denne type angreb er ICMP Flood og UDP Flood, som nu er sjældne.

Den anden kategori vinder ved snilde, smart og umærkeligt, kan det at sende en pakke hvert par minutter eller endda kun have brug for en pakke få den luksuriøse konfigurationsserver til ikke længere at reagere. Denne type angreb iværksættes hovedsageligt ved at udnytte sårbarheder i protokoller eller software, såsom Slowloris-angreb, hash-kollisionsangreb osv., og kræver specifikke miljømæssige sammentræf.

Den tredje kategori er en blanding af de to ovennævnteDet udnytter ikke kun protokollens og systemets fejl, men har også en stor mængde trafik, såsom SYN Flood-angreb og DNS Query Flood-angreb, som er den nuværende mainstream angrebsmetode.

Denne artikel vil beskrive disse mest almindelige og repræsentative angrebsmetoder én for én og introducere deres forsvarsmuligheder.

SYN Flood er et af de mest klassiske DDoS-angreb på internettet, og dukkede først op omkring 1999, hvor Yahoo var det mest berømte offer på det tidspunkt. SYN Flood-angreb udnytter TCP's triple handshake-fejl, som kan gøre målserveren uresponsiv og svær at spore til en lille pris.

Den standard TCP-trevejs-håndtryksproces er som følger:

• Klienten sender en TCP-pakke, der indeholder SYN-flaget, SYN synkroniseres, og synkroniseringspakken angiver den port, klienten bruger, samt det oprindelige serienummer på TCP-forbindelsen.
• Efter at have modtaget SYN-pakken fra klienten, returnerer serveren en SYN+ACK (dvs. bekræftelses-)pakke, som indikerer, at klientens anmodning er accepteret, og TCP's oprindelige serienummer tilføjes automatisk med 1.
• Klienten returnerer også en kvitteringsbesked ACK til serveren, og TCP-serienummeret tilføjes også med 1.
  

Efter disse tre trin etableres TCP-forbindelsen. For at opnå pålidelig transmission har TCP-protokollen opstillet nogle undtagelseshåndteringsmekanismer under de tre håndtryk. I tredje trin, hvis serveren ikke modtager den endelige ACK-kvitteringspakke fra klienten, forbliver serveren i SYN_RECV-tilstanden, tilføjer klientens IP-adresse til ventelisten og sender SYN+ACK-pakken igen i andet trin. Genopslag udføres normalt 3-5 gange, og ventelisten bliver afhørt én gang med cirka 30 sekunders mellemrum for at prøve alle klienter igen. På den anden side, efter serveren har sendt SYN+ACK-pakken ud, forudallokerer den ressourcer til at gemme information til den kommende TCP-forbindelse, som bevares, mens man venter på genforsøget. Endnu vigtigere, hvis serverressourcerne er begrænsede, vil den SYN_RECV tilstand, der kan opretholdes, ikke længere acceptere nye SYN-pakker efter at have overskredet grænsen, det vil sige, nye TCP-forbindelser vil blive afvist.

SYN Flood bruger ovenstående TCP-protokolindstillinger for at opnå formålet med angrebet. Angribere forklæder et stort antal IP-adresser for at sende SYN-pakker til serveren, og da de forfalskede IP-adresser næsten er umulige at eksistere, vil næsten ingen enhed returnere noget svar til serveren. Som følge heraf har serveren en stor venteliste og prøver gentagne gange at sende SYN+ACK-pakker, hvilket bruger mange ressourcer og ikke kan frigives. Endnu vigtigere er det, at den SYN_RECV kø på den angrebne server er fyldt med ondsindede pakker, nye SYN-anmodninger ikke længere accepteres, og legitime brugere kan ikke gennemføre tre håndtryk for at etablere TCP-forbindelser. Med andre ord blev serveren nægtet service af SYN Flood.

Hvis du er interesseret i SYN Flood, kan du tage et kig på http://www.icylife.net/yunshu/show.php?id=367, som jeg skrev i 2006, og som senere lavede flere ændringer, rettede fejl og reducerede aggressiviteten, og som udelukkende blev brugt til testning.

Som internettets mest grundlæggende og kerne-tjeneste er DNS naturligt et af de vigtige mål for DDoS-angreb. At nedlægge en DNS-tjeneste kan indirekte nedbryde en virksomheds hele forretning eller en netværkstjeneste i en region. For noget tid siden annoncerede den populære hackergruppe anonymous også, at de ville angribe 13 DNS-servere på det globale internet, men i sidste ende lykkedes det ikke.

UDP-angreb er den nemmeste angrebsmetode til at starte massiv trafik, og tilfældig kilde-IP-forfalskning er svær at spore. Dog er filtrering nemmere, fordi de fleste IP'er ikke tilbyder UDP-tjenester, så du kan bare kassere UDP-trafik. Derfor er rene UDP-trafikangreb nu relativt sjældne, og de erstattes af DNS Query Flood-angreb, som bæres af UDP-protokollen. Kort sagt lanceres DDoS-angreb på, jo højere protokollen er, desto sværere er det at forsvare sig imod, fordi jo højere protokollen er, desto mere forretningsrelateret er den, og jo mere kompleks er forsvarssystemet.

DNS Query Flood er, når en angriber manipulerer et stort antal sockpuppet-maskiner for at sende et stort antal domænenavnsforespørgsler til målet. For at forhindre ACL-baseret filtrering skal pakketilfældigheden forbedres. En almindelig praksis er tilfældigt at forfalske kilde-IP-adressen, tilfældigt forge kildeporten og andre parametre på UDP-laget. På DNS-protokollaget forfalskes forespørgsels-ID'et tilfældigt sammen med det domænenavn, der skal løses. Ud over at forhindre filtrering kan tilfældigt forfalskede domænenavne, der skal løses, også mindske sandsynligheden for at ramme DNS-cachen og forbruge så mange CPU-ressourcer som muligt fra DNS-serveren.

Med hensyn til koden til DNS Query Flood skrev jeg en kode i juli 2011 for at teste serverens ydeevne, og linket er http://www.icylife.net/yunshu/show.php?id=832. Ligeledes er denne kode kunstigt mindre aggressiv og er kun til testformål.

SYN Flood og DNS Query Flood, som beskrevet ovenfor, kan effektivt forsvares imod på dette tidspunkt, og den virkelige hovedpine for store producenter og internetvirksomheder er HTTP Flood-angreb. HTTP Flood er et angreb på en webtjeneste på en syvendelags protokol. Dens store skade manifesterer sig hovedsageligt i tre aspekter: bekvem indvielse, vanskelig filtrering og vidtrækkende konsekvenser.

Både SYN Flood og DNS Query Flood kræver, at angribere kontrollerer et stort antal bots med root-rettigheder. Det tager tid og kræfter at indsamle et stort antal root-privilegier, og under angrebet er dukkemaskinen langsom til at genopfylde på grund af angriberens hurtige tab af ressourcer på grund af unormal trafik, som administratoren opdager, hvilket resulterer i en betydelig reduktion i angrebsintensiteten og ikke kan opretholdes i lang tid. HTTP Flood-angreb er anderledes; angribere behøver ikke at kontrollere et stort antal bots, men bruger i stedet portscannere til at finde anonyme HTTP-proxies eller SOCKS-proxies på internettet, hvorigennem angriberen initierer HTTP-anmodninger til angrebsmålet. Anonyme proxies er en relativt rig ressource, og det er ikke svært at få proxies på få dage, så angreb er nemme at igangsætte og kan vare længe.

Omvendt lanceres HTTP-flood-angreb på HTTP-laget, som kraftigt efterligner websideanmodningsadfærden hos almindelige brugere, hvilket er tæt forbundet med hjemmesidebranchen, hvilket gør det vanskeligt for sikkerhedsleverandører at levere en fælles løsning, der ikke påvirker brugeroplevelsen. Regler, der fungerer godt ét sted, kan ændrede scenarier føre til mange manddrab.

Endelig kan HTTP-flood-angreb forårsage alvorlige kædereaktioner, ikke kun direkte forårsage langsom respons fra den angrebne webfront-end, men også indirekte angribe back-end Java og andre forretningslagslogikker og back-end databasetjenester, hvilket øger deres pres og endda påvirker loglagringsservere.

Interessant nok har HTTP Flood også et historisk kælenavn kaldet CC-angreb. CC er en forkortelse for Challenge Collapsar, som er en DDoS-beskyttelsesenhed fra et velkendt sikkerhedsfirma i Kina. Ud fra den nuværende situation bliver ikke kun Collapsar, men alt hardwareforsvarsudstyr stadig udfordret, og risikoen er ikke fjernet.

Når det gælder angreb, er den første reaktion massiv trafik og enorme pakker. Men der findes et angreb, der gør det modsatte, kendt for at være langsomt, så nogle angrebsmål bliver dræbt uden at vide, hvordan de dør, hvilket er slow connection-angrebet, det mest repræsentative er Slowloris opfundet af rsnake.

HTTP-protokollen fastsætter, at HTTP-anmodninger slutter på \r\n\r\n, hvilket indikerer, at klienten er færdig med at sende og serveren er begyndt at behandle. Så hvad sker der, hvis du aldrig sender \r\n\r\n? Slowloris udnytter dette til sin fordel i DDoS-angreb. Angriberen sætter forbindelsen til Keep-Alive i HTTP-anmodningsheaderen, beder webserveren om at holde TCP-forbindelsen ikke afbrudt, og sender derefter langsomt et nøgle-værdi-format til serveren hvert par minutter, såsom a:b\r\n, hvilket får serveren til at tro, at HTTP-headeren ikke er modtaget og venter. Hvis en angriber bruger multitrådning eller en marionet til det samme, vil serverens webcontainer hurtigt blive overvældet af angriberen og vil ikke længere acceptere nye forespørgsler.

Snart begyndte forskellige varianter af Slowloris at dukke op. For eksempel sender POST-metoden data til webserveren, fylder en stor indholdslængde, men langsom byte for byte POST-reelt dataindhold osv. Med hensyn til Slowloris-angrebet giver rsnake også en testkode, se http://ha.ckers.org/slowloris/slowloris.pl.

Ovenstående introducerer flere grundlæggende angrebsmetoder, hvoraf alle kan bruges til at angribe netværket og endda besejre store hjemmesider som Alibaba, Baidu og Tencent. Men det er ikke alt, forskellige niveauer af angribere kan udføre helt forskellige DDoS-angreb, og brugen af dem er det samme.

Avancerede angribere bruger aldrig én enkelt vektor til at angribe, men kombinerer dem fleksibelt baseret på målmiljøet. Almindelig SYN Flood er let at filtrere væk af trafikrensningsenheder gennem reverse detection, SYN-cookies og andre tekniske metoder, men hvis SYN+ACK-pakker blandes i SYN Flood, så hver forfalsket SYN-pakke har en tilsvarende forfalsket klientbekræftelsespakke, refererer den tilsvarende her til kilde-IP-adressen, kildeporten, destinations-IP, destinationsporten, TCP-vinduesstørrelsen, TTL osv., som alle er i overensstemmelse med karakteristikane for den samme vært og samme TCP-flow. Presset på ydeevnen af reverse detection og SYN-cookies i flowrensningsudstyr vil stige markant. Faktisk har SYN-datapakker og forskellige andre flagbits særlige angrebseffekter, som ikke introduceres her. Der findes også unikke teknikker til DNS Query Flood.

Først og fremmest kan DNS opdeles i almindelig DNS og autoriseret domæne-DNS, hvor man angriber almindelig DNS, IP-adressen skal forfalskes tilfældigt, og serveren kræver rekursiv opløsning; Men når man angriber det autoriserede domæne DNS, bør den forfalskede kilde-IP-adresse ikke være rent tilfældig, men bør være DNS-adresser fra internetudbydere verden over, indsamlet på forhånd, for at opnå maksimal angrebseffekt, så trafikrensningsenheden havner i den pinlige situation med at tilføje IP-sortliste eller ikke tilføje IP-sortliste. At tilføje det vil føre til et stort antal manddrab, og hvis du ikke tilføjer en sortliste, skal hver pakke reverse-probes, hvilket øger præstationspresset.

På den anden side, som nævnt tidligere, for at øge trykket med rengøringen af enheden, er det nødvendigt at randomisere det ønskede domænenavn uden at ramme cachen, men det skal bemærkes, at domænenavnet, der skal løses, skal have en vis regelmæssighed i forfalskningen, såsom kun at forfalske en bestemt del af domænenavnet og fastgøre en del for at bryde igennem whitelisten, som renseapparatet har sat. Årsagen er enkel: Tencents servere kan kun løse Tencents domænenavne, og helt tilfældige domænenavne kan blive kasseret direkte og skal fastlægges. Men hvis det er helt fikset, er det let at kassere det direkte, så det skal smedes.

For det andet bør angreb på DNS ikke udelukkende fokusere på UDP-porte, som også er standardtjenester ifølge DNS-protokollen. I tilfælde af et angreb kan både UDP- og TCP-angreb udføres samtidig.

Fokus i HTTP Flood er at bryde igennem cachen på frontend og direkte nå webserveren via feltindstillingerne i HTTP-headeren. Derudover er HTTP Flood også meget afgørende for valget af mål, og almindelige angribere vælger sider, der kræver mange dataforespørgsler som søgning som angrebsmål, hvilket er meget korrekt og kan forbruge så mange ressourcer som muligt på serveren. Men dette angreb er let at identificere ved rengøringsudstyr gennem menneske-maskine-identifikation, så hvordan løser man dette problem? Det er meget enkelt, prøv at vælge sider, som almindelige brugere også får adgang til via APP'en, generelt set forskellige web-API'er. Normale brugere og ondsindet trafik kommer fra APP'en, og forskellen mellem menneske og maskine er meget lille, og det er svært at skelne mellem grundlæggende integration.

Hver TCP-forbindelse eksisterer på serversiden og på sig selv, og den skal også forbruge ressourcer for at opretholde TCP-tilstanden, så forbindelsen kan ikke vedligeholdes for meget. Hvis dette kan løses, vil aggressiviteten blive markant forhøjet, det vil sige, at Slowloris kan iværksætte angreb på en tilstandsløs måde, fange TCP-serienummeret og bekræfte vedligeholdelsen af TCP-forbindelser på klienten ved at sniffe, og systemkernen behøver ikke at tage hensyn til forskellige tilstandsændringer i TCP, og en notebook kan generere op til 65.535 TCP-forbindelser.

De tidligere beskrivelser er alle tekniske angrebsforbedringer. På menneskesiden findes der andre midler. Hvis SYN Flood sender et stort antal pakker ud og ledsages af Slowloris-langsomme forbindelser, hvor mange vil så opdage hemmeligheden? Selv hvis serveren går ned, kan kun SYN-angreb findes, hvilket forsøger at styrke TCP-lagets rensning og ignorere applikationslagets adfærd. Alle slags angreb kan arbejde sammen for at opnå maksimal effekt. Valget af angrebstid er også et vigtigt punkt, såsom at vælge vedligeholdelsespersonale, når de spiser frokost, når vedligeholdelsespersonale sidder fast på vejen efter fri, eller når der ikke er signal på det trådløse netværkskort i metroen, og når målvirksomheden afholder et stort arrangement, og trafikken stiger.

Dette er et rent angreb, så der gives ingen kode eller dybdegående forklaring.

De tidligere angrebsmetoder kræver mere eller mindre nogle bots, selv HTTP Flood kræver søgning efter et stort antal anonyme proxyer. Hvis der er et angreb, behøver du kun at give nogle instruktioner, og maskinen vil automatisk komme op for at udføre det, hvilket er den perfekte løsning. Dette angreb er allerede dukket op, og det er fra P2P-netværk.

Som vi alle ved, er P2P-brugere og trafik på internettet et ekstremt stort antal. Hvis de alle går til et udpeget sted for at downloade data og forbinde tusindvis af rigtige IP-adresser, kan ingen enhed understøtte det. Tag BT-download som eksempel; at forfalske torrents af nogle populære videoer og poste dem på søgemaskiner er nok til at bedrage mange brugere og trafik, men dette er kun et grundlæggende angreb.

Avancerede P2P-angreb er direkte spoofing af ressourcestyringsservere. For eksempel vil Thunder-klienten uploade de ressourcer, den finder, til ressourcestyringsserveren og derefter sende dem til andre brugere, som har brug for at downloade de samme ressourcer, så et link bliver offentliggjort. Gennem protokolomvendelse forfalsker angribere en stor mængde populær ressourceinformation og distribuerer den gennem ressourcestyringscentret, som øjeblikkeligt kan spredes over hele P2P-netværket. Det, der er endnu mere skræmmende, er, at dette angreb ikke kan stoppes, selv ikke af angriberen selv, og angrebet fortsætter, indtil P2P-officielen finder problemet og opdaterer serveren, og downloadbrugeren genstarter den downloadede software.

Det er alt, der er i introduktionen til DDoS-angreb, og jeg vil ikke gå videre – det er nok at forstå, at så meget forsvar er nok.

Generelt kan DDoS-angreb være smidige og yndefulde. Skønheden ved anvendelse ligger i sindets enhed.