Op deze pagina
Kernpunten
- Vind de uitgeputte capaciteitEen volle verbinding, een volle verbindingstabel en een trage applicatie vragen om andere metingen en maatregelen.
- Behoud nuttige firewallregelsDDoS-bescherming vult toegangscontrole aan. De firewall uitschakelen is geen aanpak voor een incident.
- Meet de werkelijke configuratieEen geadverteerde doorvoersnelheid beschrijft niet elke pakketmix, inspectiefunctie of verbindingssnelheid.
Een firewall heeft een plaats en een beperkte capaciteit
Een firewall handhaaft toegangsbeleid, weigert ongewenst verkeer en kan afhankelijk van product en configuratie specifieke DDoS-functies of hardwareversnelling bieden. Beweren dat elke firewall bij elke DDoS-aanval faalt, is onjuist. De relevante vraag is welke capaciteit uitgeput raakt en of het apparaat daarvóór kan ingrijpen.
Een filter achter een verzadigde toegangslijn haalt legitieme pakketten die upstream verloren gingen niet terug. Omgekeerd kan een verbinding met vrije bandbreedte meer pakketbeslissingen of nieuwe toestanden aanleveren dan een bepaald systeem verwerkt. Voor gebruikers lijken deze situaties op elkaar, maar de oplossingen verschillen.
Onderscheid vier grenzen voordat u regels verandert
Verzamel deze gegevens over hetzelfde tijdvak en vermeld het meetpunt. Firewallingang, uitgang en een upstream flowsteekproef zijn niet onderling uitwisselbaar. Vergelijk een aantoonbaar gezonde periode met het incident voordat één grafiek de diagnose bepaalt.
| Onderdeel | Te verzamelen gegevens | Wat ze niet bewijzen |
|---|---|---|
| Toegangscapaciteit | Aangeboden en ontvangen bitsnelheid, upstreamverlies en interfacefouten. | Weinig ontvangen verkeer sluit verlies vóór de firewall niet uit. |
| Pakketverwerking | Pakketten per seconde, verlies in ontvangstqueues en belasting per core. | Een lage gemiddelde CPU-belasting sluit een volle queue of overbelaste worker niet uit. |
| Verbindingsstatus | Nieuwe verbindingen, toegewezen entries, grenzen en allocatiefouten. | Het aantal entries alleen identificeert geen kwaadaardige sessies. |
| Applicatiewerk | Geslaagde verzoeken, latentie, verbindingsfouten en backendbelasting. | Een HTTP-fout alleen bewijst geen DDoS-aanval op het netwerk. |
Plaats controles vóór het onderdeel dat bescherming nodig heeft
Is de toegangslijn de beperking, onderzoek dan upstreamfiltering of een beschermd afleverpad. Raakt het apparaat zelf overbelast, dan kunnen een gerichte stateless regel, ondersteunde vroege filtering of gespecialiseerde mitigatie werk wegnemen vóór dure verwerking. Applicatiemisbruik kan daarnaast authenticatie, verzoekcontroles of een geschikte proxy vereisen.
Behoud benodigde toegangsregels, beheer en besturingsverkeer. Moderne firewalls verschillen in statusbeheer, versnelling en DDoS-functies. Bekijk de echte configuratie en metingen voor de ingeschakelde functies. De labels hardware en software vertellen niet welke belasting past.
Lees statustellers voordat u een oplossing kiest
Onder Linux geeft nf_conntrack_count het aantal toegewezen flowentries aan en nf_conntrack_max de ingestelde grens. Lees deze samen met allocatiefouten en verkeersgedrag. Een stijgend aantal kan legitieme groei zijn; een laag aantal bewijst niet dat de rest van de netwerkstack gezond is.
Verhoog verbindingsgrenzen niet blind en verkort niet alle time-outs tegelijk. Geheugengebruik, bestaande sessies en protocolgedrag horen bij die afweging. Elk pakket loggen tijdens een flood kan extra werk veroorzaken en nuttige gebeurtenissen verbergen. Gebruik begrensde tellers en passende logfuncties van uw implementatie.
Voorbeeld: 12 Mpps vult niet automatisch 10 Gbit/s
Neem een hypothetische stroom van 12 miljoen minimale Ethernetframes per seconde. Met 64 bytes per frame inclusief FCS en 20 bytes voor preambule en interframetijd is de nominale lijnbezetting in één richting 8,064 Gbit/s. Dat alleen vult geen verbinding van 10 Gbit/s. Grotere frames, ander verkeer en de telmethode kunnen de uitkomst veranderen.
De berekening zegt evenmin of een bepaalde firewall de stroom kan inspecteren. Het ingestelde verwerkingspad en de belasting door statusbeheer moeten worden gemeten. Dit is een rekenvoorbeeld, geen klantincident of productbenchmark. Een firewall met een geadverteerde 40 Gbit/s is op basis van dat getal alleen niet als geschikt of overbelast te beoordelen.
Definieer succes buiten de dropteller
Leg een referentie vast
Meet legitieme pieken, pakketgroottes, nieuwe verbindingen en geslaagde applicatietransacties. Neem monitoring en beheerstoegang mee.
Reproduceer de relevante grens gecontroleerd
Gebruik een geautoriseerd geïsoleerd testpad met de bedoelde regels. Meet aangeboden belasting, afgeleverd legitiem verkeer, verlies en latentie. Belast geen gedeelde productielijn om de grens ervan te ontdekken.
Controleer de beschermde overdracht
Bevestig na filtering dat restverkeer in de ontvangende verbinding, firewall en applicatie past. Observeer nieuwe verbindingen en bestaande sessies.
Test het terugdraaien
Leg eigenaar, bereik en verwijderprocedure vast. Controleer of het intrekken van een regel het bedoelde beleid herstelt zonder andere diensten bloot te stellen.
Voorkom wijzigingen die de echte storing verhullen
- Veel drops betekenen niet dat de dienst hersteld is: controleer geslaagde klantacties.
- Schakel niet de hele firewall uit om een onverklaard prestatieprobleem te omzeilen.
- Vergelijk geen doorvoerbenchmark met grote frames met stateful inspectie van kleine pakketten.
- Neem niet aan dat upstreamfiltering elk ongewenst applicatieverzoek verwijdert.
- Verwar het gemiddelde van een kort incident niet met de hoogste pakket- of verbindingssnelheid.
Documenteer de grens van elke beschermingslaag
Leg vast welke component toegangsbeleid, paketreductie, routewijzigingen en applicatiecontroles beheert. Bewaar capaciteitsmetingen en herstelprocedures. Zo kan beheer gericht opschalen wanneer een volgend incident een ander onderdeel raakt.
Vragen en antwoorden
Kan een firewall bepaalde DDoS-aanvallen stoppen?
Ja, wanneer locatie, vrije capaciteit en ondersteunde controles bij de aanval passen. Een lokaal apparaat haalt verkeer dat al op een verzadigd upstreamtraject verloren ging niet terug.
Moet de verbindingstabel altijd groter worden?
Nee. Controleer allocatiedruk, geheugenkosten en legitieme sessiebehoeften voordat u grenzen wijzigt. Een grotere tabel lost niet elk verwerkings- of applicatieprobleem op.
Vervangt beschermd transit het firewallbeleid?
Nee. Upstreamreductie en lokale toegangscontrole hebben verschillende taken. Behoud en valideer het beleid dat de dienst nodig heeft.
