[Teknisk analyse] Grundig og lettfattelig: Introduksjon til angrep på nettverksangrep og forsvar

DDoS (Distributed Denial of Service)-angrep er noen av de kraftigste og vanskeligste angrepene å forsvare seg mot, fordi hovedformålet med DDoS-angrep er å forhindre at et utpekt mål leverer normale tjenester eller til og med forsvinner fra Internett.

DDoS kan enkelt deles inn i tre kategorier basert på hvordan de initieres.

Den første kategorien vinner med maktMassive datapakker strømmer fra alle hjørner av Internett, blokkerer inngangen til IDC, og gjør ulike kraftige maskinvareforsvarssystemer og raske og effektive nødprosesser ubrukelige. Typiske eksempler på denne typen angrep er ICMP Flood og UDP Flood, som nå er sjeldne.

Den andre kategorien vinner på kløkt, smart og umerkelig, kan det å sende en pakke hvert par minutter eller til og med bare trenge en pakke gjøre at den luksuriøse konfigurasjonsserveren ikke lenger svarer. Denne typen angrep startes hovedsakelig ved å utnytte sårbarheter i protokoller eller programvare, som Slowloris-angrep, hash-kollisjonsangrep osv., og krever spesifikke miljømessige sammentreff.

Den tredje kategorien er en blanding av de to ovennevnteDen utnytter ikke bare feilene i protokollen og systemet, men har også store mengder trafikk, som SYN Flood-angrep og DNS Query Flood-angrep, som er dagens mainstream angrepsmetode.

Denne artikkelen vil beskrive disse mest vanlige og representative angrepsmetodene én etter én og introdusere deres forsvarsalternativer.

SYN Flood er et av de mest klassiske DDoS-angrepene på Internett, og dukket først opp rundt 1999, med Yahoo som det mest kjente offeret på den tiden. SYN Flood-angrep utnytter TCPs trippel håndtrykksfeil som kan gjøre målserveren uresponsiv og vanskelig å spore til en liten kostnad.

Den standard TCP-treveis håndtrykkprosessen er som følger:

• Klienten sender en TCP-pakke som inneholder SYN-flagget, SYN synkroniseres, og synkroniseringspakken indikerer porten klienten bruker og det opprinnelige serienummeret til TCP-tilkoblingen.
• Etter å ha mottatt SYN-pakken fra klienten, vil serveren returnere en SYN+ACK (dvs. bekreftelsesbekreftelse) pakke, som indikerer at klientens forespørsel er akseptert, og TCPs initiale serienummer legges automatisk til med 1.
• Klienten returnerer også en bekreftelsesmelding ACK til serveren, og TCP-serienummeret legges også til med 1.
  

Etter disse tre trinnene etableres TCP-tilkoblingen. For å oppnå pålitelig overføring har TCP-protokollen etablert noen unntaksbehandlingsmekanismer under de tre håndtrykkene. I det tredje trinnet, hvis serveren ikke mottar den endelige ACK-bekreftelsespakken fra klienten, vil serveren forbli i SYN_RECV-tilstanden, legge klientens IP-adresse til ventelisten, og sende SYN+ACK-pakken på nytt i andre steg. Repostinger utføres vanligvis 3-5 ganger, og ventelisten sjekkes én gang med intervaller på omtrent 30 sekunder for å prøve alle klienter på nytt. På den annen side, etter at serveren har sendt ut SYN+ACK-pakken, forhåndsallokerer den ressurser for å lagre informasjon for den kommende TCP-tilkoblingen, som beholdes mens den venter på nytt forsøk. Enda viktigere, hvis serverressursene er begrenset, vil den SYN_RECV tilstanden som kan opprettholdes ikke lenger akseptere nye SYN-pakker etter at grensen er overskredet, det vil si at nye TCP-tilkoblinger vil bli avvist.

SYN Flood bruker TCP-protokollinnstillingene ovenfor for å oppnå formålet med angrepet. Angripere skjuler et stort antall IP-adresser for å sende SYN-pakker til serveren, og siden de forfalskede IP-adressene nesten er umulige å eksistere, vil nesten ingen enhet returnere noe svar til serveren. Som et resultat opprettholder serveren en lang venteliste og prøver stadig å sende SYN+ACK-pakker, noe som bruker mye ressurser og ikke kan frigjøres. Enda viktigere er det at den SYN_RECV køen til den angrepne serveren fylles med ondsinnede pakker, nye SYN-forespørsler ikke lenger aksepteres, og legitime brukere kan ikke fullføre tre håndtrykk for å etablere TCP-tilkoblinger. Med andre ord ble serveren nektet tjeneste av SYN Flood.

Hvis du er interessert i SYN Flood, kan du ta en titt på http://www.icylife.net/yunshu/show.php?id=367, som jeg skrev i 2006, og senere gjorde flere endringer, rettet feil, reduserte aggressiviteten, og som kun ble brukt til testing.

Som den mest grunnleggende og kjernetjenesten på Internett er DNS naturlig nok et av de viktige målene for DDoS-angrep. Å legge ned en DNS-tjeneste kan indirekte ødelegge hele selskapets virksomhet, eller en nettverkstjeneste i en region. For en tid siden kunngjorde den populære hackergruppen anonymous også at de ville angripe 13 DNS-servere på det globale Internett, men til slutt lyktes de ikke.

UDP-angrep er den enkleste angrepsmetoden for å initiere massiv trafikk, og tilfeldig kilde-IP-forfalskning er vanskelig å spore. Filtrering er imidlertid enklere fordi de fleste IP-adresser ikke tilbyr UDP-tjenester, så du kan bare forkaste UDP-trafikk. Derfor er rene UDP-trafikkangrep nå relativt sjeldne, og de erstattes av DNS Query Flood-angrep som bæres av UDP-protokollen. Enkelt sagt, DDoS-angrep som startes på jo høyere protokollen er, desto vanskeligere er det å forsvare seg mot, fordi jo høyere protokollen er, desto mer forretningsrelatert er den, og jo mer kompleks er forsvarssystemet.

DNS Query Flood er når en angriper manipulerer et stort antall sockpuppet-maskiner for å sende et stort antall domenenavnsforespørselsforespørsler til målet. For å forhindre ACL-basert filtrering må pakketilfeldigheten forbedres. En vanlig praksis er å tilfeldig smi kilde-IP-adressen, tilfeldig smi kildeporten og andre parametere på UDP-laget. På DNS-protokolllaget forfalskes spørrings-ID-en tilfeldig sammen med domenenavnet som skal løses. I tillegg til å forhindre filtrering, kan tilfeldige forfalskede domenenavn som skal løses også redusere sannsynligheten for å treffe DNS-cachen og bruke så mye CPU-ressurser som mulig på DNS-serveren.

Når det gjelder koden for DNS Query Flood, skrev jeg en kode i juli 2011 for å teste serverytelsen, og lenken er http://www.icylife.net/yunshu/show.php?id=832. På samme måte er denne koden kunstig mindre aggressiv og er kun for testformål.

SYN Flood og DNS Query Flood beskrevet ovenfor kan effektivt forsvares mot på dette stadiet, og den virkelige hodepinen for store produsenter og internettbedrifter er HTTP Flood-angrep. HTTP Flood er et angrep på en webtjeneste på en syvendelags protokoll. Den store skaden manifesterer seg hovedsakelig i tre aspekter: praktisk initiering, vanskelig filtrering og vidtrekkende konsekvenser.

Både SYN Flood og DNS Query Flood krever at angripere kontrollerer et stort antall boter med rot-privilegier. Det tar tid og innsats å samle et stort antall rotprivilegier, og under angrepet er dukkemaskinen treg med å fylle på på grunn av angriperens raske tap av ressurser på grunn av unormal trafikk oppdaget av administratoren, noe som resulterer i en betydelig reduksjon i angrepsintensiteten og som ikke kan opprettholdes over lang tid. HTTP Flood-angrep er annerledes; angripere trenger ikke å kontrollere et stort antall roboter, men bruker i stedet portskannere for å finne anonyme HTTP-proxyer eller SOCKS-proxyer på Internett, hvor angriperen initierer HTTP-forespørsler til angrepsmålet. Anonyme proxyer er en relativt rik ressurs, og det er ikke vanskelig å skaffe proxyer på noen få dager, så angrep er enkle å starte og kan vare lenge.

På den annen side iverksettes HTTP-flomangrep på HTTP-laget, som kraftig etterligner nettsideforespørselsoppførselen til vanlige brukere, noe som er nært knyttet til nettsidevirksomheten, noe som gjør det vanskelig for sikkerhetsleverandører å tilby en felles løsning som ikke påvirker brukeropplevelsen. Regler som fungerer godt på ett sted, og endrede scenarioer kan føre til mange tilfeller av uaktsomt drap.

Til slutt kan HTTP-flomangrep forårsake alvorlige kjedereaksjoner, ikke bare direkte føre til treg respons fra den angrepne webfrontenden, men også indirekte angripe back-end Java og annen forretningslags-logikk og back-end databasetjenester, øke presset og til og med påvirke logglagringsservere.

Interessant nok har HTTP Flood også et historisk kallenavn kalt CC-angrep. CC er en forkortelse for Challenge Collapsar, som er en DDoS-beskyttelsesenhet fra et velkjent sikkerhetsselskap i Kina. Ut fra dagens situasjon blir ikke bare Collapsar, men alt utstyr og forsvarsutstyr fortsatt utfordret, og risikoen er ikke fjernet.

Når det gjelder angrep, er den første reaksjonen massiv trafikk og enorme pakker. Men det finnes et angrep som gjør det motsatte, kjent for å være tregt, slik at noen angrepsmål blir drept uten å vite hvordan de dør, nemlig slow connection-angrepet, det mest representative er Slowloris oppfunnet av rsnake.

HTTP-protokollen krever at HTTP-forespørsler slutter på \r\n\r\n, noe som indikerer at klienten er ferdig med sendingen og serveren har startet behandlingen. Så hva skjer hvis du aldri sender \r\n\r\n? Slowloris bruker dette til sin fordel i DDoS-angrep. Angriperen setter tilkoblingen til Keep-Alive i HTTP-forespørselsheaderen, ber webserveren om å holde TCP-tilkoblingen ikke frakoblet, og sender deretter sakte et nøkkel-verdi-format til serveren hvert par minutter, som a:b\r\n, noe som får serveren til å tro at HTTP-headeren ikke er mottatt og venter. Hvis en angriper bruker multitråding eller en marionett for å gjøre det samme, vil serverens webcontainer raskt bli overveldet av angriperen og ikke lenger akseptere nye forespørsler.

Snart begynte ulike varianter av Slowloris å dukke opp. For eksempel sender POST-metoden data til webserveren, fyller en stor innholdslengde, men langsom byte for byte POST-innhold med reelle data, osv. Når det gjelder Slowloris-angrepet, gir rsnake også en testkode, se http://ha.ckers.org/slowloris/slowloris.pl.

Ovenstående introduserer flere grunnleggende angrepsmetoder, hvor alle kan brukes til å angripe nettverket, og til og med beseire gigantiske nettsteder som Alibaba, Baidu og Tencent. Men det er ikke alt, ulike nivåer av angripere kan gjennomføre helt forskjellige DDoS-angrep, og bruken av dem er det samme.

Avanserte angripere bruker aldri én enkelt vektor for å angripe, men kombinerer dem fleksibelt basert på målmiljøet. Vanlig SYN Flood er lett å filtrere ut av trafikkrensingsenheter gjennom omvendt deteksjon, SYN-informasjonskapsler og andre tekniske metoder, men hvis SYN+ACK-pakker blandes i SYN Flood, slik at hver forfalsket SYN-pakke har en tilsvarende forfalsket klientbekreftelsespakke, refererer den tilsvarende her til kilde-IP-adressen, kildeporten, destinasjons-IP, destinasjonsporten, TCP-vindusstørrelsen, TTL osv. som alle samsvarer med egenskapene til samme vert og samme TCP-flyt. Presset på ytelsen til reverseringsdeteksjon og SYN-cookies i flow cleaning-utstyr vil øke betydelig. Faktisk har SYN-datapakker og ulike andre flaggbiter spesielle angrepseffekter, som ikke er introdusert her. Det finnes også unike teknikker for DNS Query Flood.

Først og fremst kan DNS deles inn i vanlig DNS og autorisert domene-DNS, som angriper vanlig DNS, IP-adressen må forfalskes tilfeldig, og serveren krever rekursiv oppløsning; Men når man angriper det autoriserte domenets DNS, bør den forfalskede kilde-IP-adressen ikke være helt tilfeldig, men DNS-adressene til internettleverandører over hele verden samlet inn på forhånd, for å oppnå maksimal angrepseffekt, slik at trafikkrensingsenheten havner i den pinlige situasjonen med å legge til IP-svarteliste eller ikke legge til IP-svarteliste. Å legge det til vil føre til mange uaktsomt drap, og hvis du ikke legger til en svarteliste, må hver pakke reversproberes, noe som øker ytelsespresset.

På den annen side, som nevnt tidligere, for å øke trykket med å rense enheten, er det nødvendig å randomisere det forespurte domenenavnet uten å treffe cachen, men det bør bemerkes at domenenavnet som skal løses må ha en viss regelmessighet i forfalskningen, som å forfalske kun en viss del av domenenavnet og gjøre en del fastmontert for å bryte gjennom hvitelisten satt av rengjøringsenheten. Grunnen er enkel: Tencents servere kan bare løse Tencents domenenavn, og helt tilfeldige domenenavn kan bli direkte forkastet og må bekreftes. Men hvis den er helt fikset, er det lett å kaste den direkte, så den må smides.

For det andre bør angrep på DNS ikke kun fokusere på UDP-porter, som også er standardtjenester i henhold til DNS-protokollen. Ved et angrep kan både UDP- og TCP-angrep utføres samtidig.

Fokuset med HTTP Flood er å bryte gjennom cachen på frontenden og direkte nå webserveren via feltinnstillingene i HTTP-headeren. I tillegg er HTTP Flood også svært kritisk for valg av mål, og vanlige angripere velger sider som krever mange datasøk, som søk, som angrepsmål, noe som er svært korrekt og kan bruke så mange ressurser som mulig på serveren. Men dette angrepet er lett å identifisere ved rengjøring av utstyr gjennom menneske-maskin-identifikasjon, så hvordan løser man dette problemet? Det er veldig enkelt, prøv å velge sider som vanlige brukere også får tilgang til via APPEN, generelt sett ulike web-API-er. Vanlige brukere og ondsinnet trafikk kommer fra APPEN, og forskjellen mellom menneske og maskin er veldig liten, og det er vanskelig å skille mellom grunnleggende integrasjon.

Hver TCP-tilkobling eksisterer på serversiden og på seg selv, og den må også bruke ressurser for å opprettholde TCP-tilstanden, så forbindelsen kan ikke opprettholdes for mye. Hvis dette kan løses, vil aggressiviteten bli betydelig økt, det vil si at Slowloris kan starte angrep på en tilstandsløs måte, fange TCP-serienummeret og bekrefte vedlikehold av TCP-tilkoblinger på klienten ved å sniffe, og systemkjernen trenger ikke å følge med på ulike tilstandsendringer i TCP, og en notatbok kan generere opptil 65 535 TCP-tilkoblinger.

De tidligere beskrivelsene er alle tekniske angrepsforbedringer. På menneskesiden finnes det andre metoder. Hvis SYN Flood sender ut et stort antall pakker og ledsages av Slowloris slow-forbindelser, hvor mange vil oppdage hemmeligheten? Selv om serveren går ned, kan bare SYN-angrep finnes, noe som prøver å styrke TCP-lagets rensing og ignorere applikasjonslagets oppførsel. Alle typer angrep kan samarbeide for å oppnå maksimal effekt. Valget av angrepstid er også et viktig punkt, som å velge vedlikeholdspersonell når de spiser lunsj, når vedlikeholdspersonell sitter fast på veien etter slutt på jobb eller når det ikke er signal på det trådløse nettverkskortet i t-banen, og når målbedriften holder et stort arrangement og trafikken øker.

Dette er et rent angrep, så det gis ingen kode eller grundig forklaring.

De tidligere angrepsmetodene krever mer eller mindre noen bots, selv HTTP Flood krever søk etter et stort antall anonyme proxyer. Hvis det er et angrep, trenger du bare å gi noen instruksjoner, og maskinen vil automatisk komme opp for å utføre det, noe som er den perfekte løsningen. Dette angrepet har allerede dukket opp, og det er fra P2P-nettverk.

Som vi alle vet, er P2P-brukere og trafikk på Internett et ekstremt stort antall. Hvis de alle går til et bestemt sted for å laste ned data og koble tusenvis av ekte IP-adresser, kan ingen enhet støtte det. Ta BT-nedlasting som et eksempel, å forfalske torrenter av noen populære videoer og legge dem ut på søkemotorer er nok til å lure mange brukere og trafikk, men dette er bare et grunnleggende angrep.

Avanserte P2P-angrep er direkte forfalskning av ressursforvaltningsservere. For eksempel vil Thunder-klienten laste opp ressursene den finner til ressurshåndteringsserveren, og deretter sende dem til andre brukere som trenger å laste ned de samme ressursene, slik at en lenke blir publisert. Gjennom protokollreversering forfalsker angripere store mengder populær ressursinformasjon og distribuerer den gjennom ressursforvaltningssenteret, som kan spres umiddelbart gjennom hele P2P-nettverket. Det som er enda mer skremmende, er at dette angrepet ikke kan stoppes, ikke engang av angriperen selv, og angrepet fortsetter til P2P-offiseren finner problemet og oppdaterer serveren, og brukeren starter den nedlastede programvaren på nytt.

Det er alt som er i introduksjonen til DDoS-angrep, og jeg vil ikke gå videre – det er nok å forstå at så mye forsvar er nok.

Generelt kan DDoS-angrep være smidige og grasiøse. Skjønnheten ved anvendelse ligger i sinnets enhet.