[Sikkerhetsveiledning] SYN Flood-angrep, SYN-informasjonskapselforsvar og modifisering av kjerneparametere for Linux/FreeBSD

HackerDet er en ønskelig og lovende karriere. Jeg setter pris på gode hackere og hater dårlige hackere. Den såkalte dårlige hackeren er typen som får noen på den andre siden til å jobbe overtid.

    SYN Flood-angrep er et typisk tjenestenektangrep. Det såkalte tjenestenektangrepet er for indirekte å oppnå formålet med angrepet ved å gjøre offerets vert eller nettverk ute av stand til å levere god tjeneste. Hackere liker å spille dette for å vise at de er jevne, dyktige og modige ved å få den andre parten til å jobbe overtid, men i realiteten er det ingenting.

   1: Hva er et SYN Flood-angrep?

    SYN Flood-angrep utnytter den treveis håndtrykksprosessen i TCP-protokollen i IPv4. Denne protokollen fastsetter at hvis den ene enden ønsker å initiere en TCP-forbindelse til den andre enden, må den først sende en TCP SYN (synkronisere)-pakke til den andre parten, og den andre parten sender en TCP SYN + ACK-pakke tilbake etter mottak, og deretter sender initiativtakeren en TCP ACK (ACKnowledge Character)-pakke tilbake, slik at de tre håndtrykkene er over.

    I prosessen ovenfor finnes det noen viktige konsepter:

    Køen er ikke koblet sammen: I treveis håndtrykkprotokollen opprettholder serveren en ukoblet kø som åpner en oppføring for hver klients SYN-pakke (syn=j) som indikerer at serveren har mottatt SYN-pakken og gir en bekreftelse til kunden, mens den venter på kundens bekreftelsespakke. Tilkoblingen identifisert av disse oppføringene er i en Syn_RECV tilstand på serveren, og når serveren mottar en bekreftelsespakke fra kunden, slettes oppføringen og serveren går inn i ETABLERT-tilstanden. Med andre ord, når TCP-serveren mottar TCP SYN-forespørselspakken, må TCP-serveren først allokere et dataområde for å betjene TCP-tilkoblingen dannet av denne hånden før TCP SYN+ACK-pakken sendes tilbake til TCP-klienten. Generelt er tilkoblingstilstanden når SYN-pakken mottas, men ACK-pakken ennå ikke er mottattHalvåpen forbindelse(Halvåpen forbindelse)。

    Backlog-parameter: Indikerer maksimalt antall ukoblede køer.

    SYN-ACK antall retransmisjoner: Etter at serveren har sendt SYN-ACK-pakken, hvis kundebekreftelsespakken ikke mottas, utfører serveren den første retransmisjonen, venter en periode og mottar ikke kundebekreftelsespakken, og utfører den andre retransmisjonen. Hvis antallet retransmisjoner overstiger det maksimale antallet retransmisjoner spesifisert av systemet, sletter systemet tilkoblingsinformasjonen fra semi-tilkoblingskøen. Merk at ventetiden for hver omgang ikke nødvendigvis er den samme.

    Semi-sammenhengende overlevelsestid: Refererer til maksimal tid en oppføring i semi-tilkoblingskøen overlever, det vil si maksimal tid fra tjenesten mottar SYN-pakken til pakken bekreftes som ugyldig, og tidsverdien er summen av maksimal ventetid for alle retransmisjonsforespørsler. Noen ganger kaller vi også semi-sammenkoblet overlevelsestid, SYN_RECV overlevelsestid.

    I det vanligste SYN-flomangrepet sender angriperen et stort antall TCP SYN-pakker til offeret på kort tid, hvor angriperen er TCP-klienten og offeret er TCP-serveren. Ifølge beskrivelsen ovenfor ville offeret tildele en spesifikk datasone til hver TCP SYN-pakke, så lenge SYN-pakkene hadde forskjellige kildeadresser (noe som ville være lett for angripere å forfalske). Dette vil legge mye press på TCP-serversystemet og til slutt føre til at systemet ikke fungerer som det skal.

    2. Prinsippet om SYN-informasjonskapsler

    En av måtene å effektivt forhindre SYN Flood-angrep på er SYN-informasjonskapsler. SYN Cookie Årsak D. Oppfunnet av J. Bernstain og Eric Schenk.

    SYN-informasjonskapsler er en modifikasjon av TCPs serverside treveis håndtrykkprotokoll for å forhindre SYN Flood-angrep.Prinsippet er:Når TCP-serveren mottar en TCP SYN-pakke og returnerer en TCP SYN+ACK-pakke, allokerer den ikke et dedikert dataområde, men beregner en informasjonskapselverdi basert på denne SYN-pakken. Når en TCP ACK-pakke mottas, sjekker TCP-serveren legitimiteten til TCP ACK-pakken basert på den cookie-verdien. Hvis det er lovlig, er et dedikert dataområde avsatt for å håndtere fremtidige TCP-tilkoblinger.

    La oss snakke om hvordan man konfigurerer kjerneparametere for å implementere SYN-informasjonskapsler i Linux og FreeBSD

    Tre: Linux-innstillinger

    Hvis serverkonfigurasjonen din ikke er god, når antallet TCP TIME_WAIT sockets 20 000 eller 30 000, og serveren kan lett bli dratt i hjel. Ved å endre Linux-kjerneparametrene kan antallet TIME_WAIT sokler på serveren reduseres.

    TIME_WAIT kan sees med følgende kommando:

På Linux, som CentOS, kan du oppnå dette ved å endre filen /etc/sysctl.conf.

    Legg til følgende linjer:

Illustrere:

net.ipv4.tcp_syncookies = 1 betyr at SYN-informasjonskapsler er aktivert, som er en BOOLEAN. Når SYN venter på at køen skal flyte over, aktiver informasjonskapsler for å håndtere den, noe som kan forhindre et lite antall SYN-angrep, og standard er 0, noe som betyr at den er stengt.
net.ipv4.tcp_tw_reuse = 1 betyr at gjenbruk er aktivert, som er en BOOLEAN. Tillater gjenbruk av TIME-WAIT-sokler for nye TCP-tilkoblinger, med standard 0, som indikerer lukking;
net.ipv4.tcp_tw_recycle = 1 betyr å muliggjøre rask resirkulering av TIME-WAIT-sokler i TCP-tilkoblinger, som er en BOOLEAN, og standard er 0, noe som betyr at den er lukket.
net.ipv4.tcp_fin_timeout = 30 betyr at hvis socketen lukkes av en lokal forespørsel, bestemmer denne parameteren hvor lenge den vil forbli i FIN-WAIT-2-tilstanden. Enheten er sekunder.
net.ipv4.tcp_keepalive_time = 1200 indikerer hvor ofte TCP sender keepalive-meldinger når keepalive brukes. Standard er 2 timer, endret til 20 minutter. Enheten er sekunder.
net.ipv4.ip_local_port_range = 1024 65000 indikerer rekkevidden av porter som brukes for utgående tilkoblinger. Standardtilfellet er liten: 32768 til 61000, endret til 1024 til 65000.
net.ipv4.tcp_max_syn_backlog = 8192 angir lengden på SYN-køen, som som standard er 1024, og lengden på den økte køen er 8192 for å imøtekomme flere nettverkstilkoblinger som venter på tilkobling.
net.ipv4.tcp_max_tw_buckets = 5000 angir det maksimale antallet sokler systemet opprettholder TIME_WAIT samtidig, og hvis dette antallet overskrides, vil TIME_WAIT sokler umiddelbart bli slettet og en advarselsmelding vil bli skrevet ut. Standard er 180000, endret til 5000. For servere som Apache og Nginx kan parameterne i de forrige linjene redusere antall sokler TIME_WAIT godt, men for Squid er effekten ikke så god. Denne parameteren styrer maksimalt antall TIME_WAIT sokler for å forhindre at Squid-serveren blir dratt ut av et stort antall TIME_WAIT sokler.
net.ipv4.tcp_synack_retries og net.ipv4.tcp_syn_retries definerer antall SYN-forsøk.

Kjør følgende kommando for å få konfigurasjonen til å tre i kraft:

Hvis du ikke vil endre /etc/sysctl.conf, kan du også bruke kommandoen til å gjøre det:

For det fjerde, satt opp under FreeBSD

    yayus personlige læringssynspunkt: forsvaret mot SYN i FreeBSD er kanskje ikke det samme som i Linux, parameterne som er konfigurert er ikke helt de samme, og den relevante konfigurasjonen og forståelsen kan være ukorrekt :)

    Det finnes en i TCP-linkenMSL (maks segmentlevetid)BegrepetMaksimal generasjonstidMSL-verdien tas i 30 sekunder i generelle implementasjoner, og noen implementasjoner tar 2 minutter. "Passiv avstengning" i TCP-tilstandsmaskinen: Fra CLOSE_WAIT til LAST_ACK finnes en regel som følger: Når TCP utfører en aktiv nedstengning og sender tilbake den siste ACK-en, må forbindelsen forbli i TIME_WAIT-tilstanden dobbelt så lenge som MSL. Dette gjør at TCP kan sende den siste ACK-en på nytt hvis den går tapt (den andre enden går ut og sender den siste FIN-en på nytt).

    Eksistensen av denne regelen har den konsekvens at lenken (klientadresse, port og serverside-adresse, port) på den adressen ikke kan brukes i løpet av denne 2*MSL-tiden. For eksempel, hvis vi lukker en lenke etter opprettelsen og deretter raskt starter lenken på nytt, vil porten være utilgjengelig.

    TIME_WAIT tid er 2*MSL. Så du kan redusere TIME_WAIT tid ved å justere net.inet.tcp.msl. For webserveren kan denne verdien justeres til 7500 eller 2000 (tilgang til et web, siden kan ikke flashes i mer enn 4~15 sekunder, du kan vurdere å gi opp -_-)

    Parameterinnstillingsreferanse:

På FreeBSD så ikke Yayu en kommando som "/sbin/sysctl -p" som kunne gjøre innholdet i /etc/sysctl.conf effektivt, så han brukte bare kommandoen: