Cookie necessari
Requisiti di implementazione
Protezione DDoS per ISP e operatori di rete
Proteggere una rete di accesso significa preservare i percorsi condivisi da molti abbonati mantenendo prevedibili responsabilità di routing e connessioni. Partite dai prefissi gestiti e dalla risorsa che si esaurisce per prima.
Tre confini importanti in una rete di accesso
- Collegamenti condivisi e destinazioni distribuite
- Un attacco su più indirizzi può saturare un uplink condiviso senza che una singola destinazione domini il grafico. Osservate prefissi, upstream e singoli indirizzi: un endpoint tranquillo non dimostra capacità residua sul percorso aggregato.
- Stato degli abbonati e sorgenti condivise
- CGNAT e apparati stateful possono subire pressione sulle connessioni indipendentemente dalla banda. Più utenti legittimi possono condividere lo stesso IP sorgente pubblico. Un limite per sorgente richiede quindi una valutazione del traffico, non una soglia bassa per tutti.
- Più responsabili del routing
- Prefissi propri, annunci dei clienti e indirizzi assegnati dal provider possono avere autorizzazioni e regole di export diverse. Definite perimetro protetto, annunci accettati e aspettative sulla route predefinita prima di aggiungere un percorso.
Combinare la consegna upstream con i controlli che gestite
Transit IP protetto può fornire il livello di rete; il filtraggio locale compatibile può svolgere un ruolo distinto a valle. Anche un progetto ibrido richiede responsabilità esplicite per deviazione, filtraggio e ripristino.
Osservare i percorsi esposti
Raccogliete telemetria dei router e contatori delle interfacce indicando intervallo di campionamento e direzione.
Consegnare il traffico protetto
Verificate tunnel o collegamento fisico concordato, selezione delle route, MTU e capacità residua di consegna.
Preservare il servizio degli abbonati
Verificate traffico di ritorno e normali applicazioni con le modalità TCP e stateful locali selezionate.
Sequenza indicativa. Il preventivo e il verbale di collaudo definiscono il servizio fornito.
Decisioni da prendere prima dell'ordine
- Chi può annunciare i prefissi protetti?
- Documentate ASN, autorizzazione dei prefissi, filtri di routing e propagazione consentita. Una sessione BGP attiva non dimostra che le route desiderate siano accettate.
- Il traffico di ritorno può evitare il filtro locale?
- Dipende dalla modalità di protezione scelta. Verificate i requisiti reali di routing prima di attivare funzioni stateful; più peer non implicano supporto al routing asimmetrico.
- Che cosa può attivare una deviazione?
- Distinguete osservazione, autorizzazione e applicazione. Peeryx Flow Collector opera fuori dal percorso e usa il perimetro pubblicato di deviazione IPv4 /24 autorizzata; non fornisce capacità di rete né filtraggio inline.
Dimostrare che il servizio di accesso supera la modifica concordata
- Registrate traffico normale nelle ore di punta, connessioni riuscite e contatori di stato prima di attivare la protezione.
- Verificate route accettate, entrambe le direzioni e trasferimenti piccoli e grandi su ogni percorso consegnato.
- Coordinate il test di guasto del percorso o apparato scelto, misurate il ripristino del servizio utile e designate un responsabile del rollback.
Domande su questa implementazione
La capacità condivisa della rete è riservata al mio ISP?
No. Commit, porta di consegna, capacità upstream condivisa e capacità locale misurata sono grandezze distinte. La proposta applicabile definisce il servizio fornito.
Un filtro locale può sostituire la protezione upstream su un accesso saturo?
Non può recuperare pacchetti già persi prima di raggiungerlo. La protezione che deve alleggerire il collo di bottiglia va posizionata a monte di esso.
Riferimento tecnico : RFC 7454: gestione e sicurezza BGP