{"id":31057,"date":"2019-10-31T21:39:12","date_gmt":"2019-10-31T18:39:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-vtoraya\/"},"modified":"2019-10-31T21:39:12","modified_gmt":"2019-10-31T18:39:12","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-vtoraya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-vtoraya","title":{"rendered":"Come prendere il controllo dell'infrastruttura di rete. Capitolo terzo. Sicurezza di rete. Parte seconda","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i>Questo articolo \u00e8 il quarto di un ciclo di articoli intitolato \"Come controllare l'infrastruttura di rete\". I contenuti di tutti gli articoli del ciclo e i link possono essere trovati <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/447008\/\">qui<\/a><\/noindex><\/i>.<\/p>\n<p>In <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/435138\/\">prima parte<\/a><\/noindex> In questo capitolo abbiamo esaminato alcuni aspetti della sicurezza della rete nel segmento \"Data Center\". Questa parte sar\u00e0 dedicata al segmento \"Internet Access\". <\/p>\n<p><img decoding=\"async\" alt=\"Come prendere il controllo dell&#039;infrastruttura di rete. Capitolo terzo. Sicurezza di rete. Parte seconda\" src=\"\/wp-content\/uploads\/2019\/04\/10b33f9b02e3a7562d9e7cf023cbc197.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Accesso a Internet<\/h1>\n<p>\nIl tema della sicurezza \u00e8 senza dubbio uno dei pi\u00f9 complessi del mondo delle reti di trasmissione dei dati. Come nei casi precedenti, senza pretendere di essere esaustivo e dettagliato, discuter\u00f2 qui alcune questioni abbastanza semplici ma, secondo me, importanti, le cui risposte spero possano contribuire a migliorare il livello di sicurezza della vostra rete.<\/p>\n<p>Durante l'audit di questo segmento, prestate attenzione ai seguenti aspetti:<\/p>\n<ul>\n<li>design<\/li>\n<li>configurazioni BGP <\/li>\n<li>protezione DOS\/DDOS<\/li>\n<li>filtraggio del traffico sul firewall<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Design<\/h3>\n<p>\nCome esempio di design per questo segmento in una rete aziendale, raccomanderei <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/dam\/en\/us\/solutions\/collateral\/enterprise\/design-zone-security\/safe-architecture-guide-pin-secure-internet-edge.pdf\">guida<\/a><\/noindex> di Cisco all'interno del <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/solutions\/enterprise\/design-zone-security\/landing_safe.html#~tab-architecture\">modello SAFE<\/a><\/noindex>.<\/p>\n<p>Naturalmente, potrebbe sembrare che le soluzioni di altri fornitori siano pi\u00f9 attraenti (vedi <noindex><a rel=\"nofollow\" href=\"https:\/\/researchcenter.paloaltonetworks.com\/2018\/10\/palo-alto-networks-seven-time-gartner-magic-quadrant-leader\/\">quadrante Gartner del 2018<\/a><\/noindex>), ma, senza invitarvi a seguire questo design nei dettagli, ritengo comunque utile comprendere i principi e le idee sottostanti.<\/p>\n<blockquote><p><b>Nota<\/b><\/p>\n<p>Nel modello SAFE, il segmento \"Remote Access\" fa parte di \"Internet Access\". Ma in questo ciclo di articoli lo esamineremo separatamente.<\/p><\/blockquote>\n<p>L'insieme standard di attrezzature per questo segmento per una rete aziendale \u00e8 composto da <\/p>\n<ul>\n<li>router di confine (border routers)<\/li>\n<li>firewall<\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p><b>Nota 1<\/b><\/p>\n<p>In questo ciclo di articoli, quando parlo di firewall, intendo <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Next-generation_firewall\">NGFW<\/a><\/noindex>.<\/p><\/blockquote>\n<blockquote><p><b>Nota 2<\/b><\/p>\n<p>Mi astengo dal considerare vari tipi di soluzioni L2\/L1 o L2 over L3 necessarie per garantire la connettivit\u00e0 L1\/L2 e mi limito solo a questioni di livello L3 e oltre. In parte, le questioni L1\/L2 sono state trattate nel capitolo &#171;<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/434750\/\">Pulizia e documentazione<\/a><\/noindex>&#171;.<\/p><\/blockquote>\n<p> Se non avete trovato un firewall in questo segmento, non affrettatevi a fare conclusioni.<\/p>\n<p>Diamo, come in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/435138\/\">parte precedente<\/a><\/noindex>, iniziamo dalla domanda se sia necessario utilizzare un firewall in questo segmento nel vostro caso.<\/p>\n<p>Posso dire che, apparentemente, questo \u00e8 il posto pi\u00f9 giustificato per l'uso di firewall e per l'applicazione di algoritmi complessi di filtraggio del traffico. Nella <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/435138\/\">parte 1<\/a><\/noindex> abbiamo menzionato 4 fattori che possono ostacolare l'uso dei firewall nel segmento dei data center. Ma qui non sono pi\u00f9 cos\u00ec significativi.<\/p>\n<blockquote><p>Esempio 1. <b>Ritardo<\/b><\/p>\n<p>Quando si tratta di internet, non ha senso parlare di ritardi anche di solo 1 millisecondo. Pertanto, i ritardi in questo segmento non possono rappresentare un fattore limitante per l'uso del firewall.<\/p><\/blockquote>\n<blockquote><p>Esempio 2. <b>Prestazioni<\/b><\/p>\n<p>In alcuni casi, questo fattore pu\u00f2 ancora essere significativo. Pertanto, potrebbe essere necessario deviare parte del traffico (ad esempio, il traffico dei bilanciatori di carico) bypassando il firewall.<\/p><\/blockquote>\n<blockquote><p>Esempio 3. <b>Affidabilit\u00e0<\/b><\/p>\n<p>Questo fattore deve ancora essere considerato, ma tenendo conto dell'affidabilit\u00e0 dell'internet stesso, la sua importanza per questo segmento non \u00e8 cos\u00ec significativa come per il data center. <\/p>\n<p>Supponiamo che il tuo servizio funzioni su http\/https (con sessioni brevi). In questo caso puoi utilizzare due box indipendenti (senza HA) e in caso di problemi con uno di essi, instradare tutto il traffico sul secondo. <\/p>\n<p>Oppure puoi utilizzare i firewall in modalit\u00e0 trasparente e, in caso di guasto, deviare temporaneamente il traffico bypassando i firewall.<\/p><\/blockquote>\n<p> Pertanto, \u00e8 probabile che sia proprio solo <b>il prezzo<\/b> il fattore che ti costringer\u00e0 a rinunciare all'utilizzo dei firewall in questo segmento.<\/p>\n<blockquote><p><b>Importante!<\/b><\/p>\n<p>C'\u00e8 la tentazione di combinare questo firewall con quello del data center (utilizzando un unico firewall per questi segmenti). Questa soluzione \u00e8 teoricamente possibile, ma \u00e8 importante comprendere che, poich\u00e9 il firewall 'Internet Access' si trova effettivamente in prima linea nella tua difesa e 'prende su di s\u00e9', almeno in parte, il traffico malevolo, \u00e8 necessario considerare l'aumento del rischio che questo firewall possa guastarsi. Cio\u00e8, utilizzando gli stessi dispositivi in questi due segmenti, ridurrai sostanzialmente la disponibilit\u00e0 del segmento del tuo data center.<\/p><\/blockquote>\n<p> Come al solito, \u00e8 necessario comprendere che a seconda del servizio fornito dall'azienda, il design di questo segmento pu\u00f2 variare significativamente. Puoi, come al solito, scegliere diversi approcci a seconda delle esigenze. <\/p>\n<blockquote><p><b>Esempio<\/b><\/p>\n<p>Se sei un provider di contenuti, con una rete CDN (vedi, ad esempio, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/ramax\/posts\/\">un insieme di articoli<\/a><\/noindex>), potresti non voler creare decine, se non centinaia, di punti di presenza nell'infrastruttura utilizzando dispositivi separati per l'instradamento e la filtrazione del traffico. Questo sarebbe costoso e potrebbe anche essere semplicemente superfluo. <\/p>\n<p>Per BGP non \u00e8 affatto necessario avere router dedicati; puoi utilizzare strumenti open-source, per esempio, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.quagga.net\">Quagga<\/a><\/noindex>. Pertanto, potrebbe bastarti un server o pi\u00f9 server, uno switch e BGP.<\/p>\n<p>In questo caso, il tuo server o pi\u00f9 server possono svolgere il ruolo non solo di server CDN, ma anche di router. Certo, ci sono ancora molti dettagli qui (ad esempio, come garantire il bilanciamento), ma \u00e8 realizzabile, e questo approccio \u00e8 stato applicato con successo per uno dei nostri partner.<\/p>\n<p>Puoi avere diversi data center con protezione completa (firewall, servizi di protezione da attacchi DDoS forniti dai tuoi provider di servizi internet) e decine o centinaia di punti di presenza \"semplificati\" solo con switch L2 e server.<\/p>\n<p>E riguardo alla protezione in questo caso?<\/p>\n<p>Prendiamo in considerazione, ad esempio, la popolare <noindex>attacco DDoS di amplificazione DNS<\/noindex>. La sua pericolosit\u00e0 risiede nel fatto che viene generato un grande volume di traffico, che semplicemente \"intasa\" al 100% tutti i tuoi uplink. <\/p>\n<p>Cosa abbiamo nel caso del nostro design.<\/p>\n<ul>\n<li>se utilizzi AnyCast, il traffico viene distribuito tra i tuoi punti di presenza. Se la larghezza di banda totale \u00e8 in terabits, questo di per s\u00e9 ti protegge (anche se ultimamente ci sono state alcune attacchi con traffico dannoso dell'ordine di un terabit) da \"saturare\" gli uplink.<\/li>\n<li>se comunque alcuni uplink \"si intasano\", puoi semplicemente dismettere quella piattaforma (smettendo di annunciare il prefisso).<\/li>\n<li>Puoi anche aumentare la percentuale di traffico proveniente dai tuoi data center \"completi\" (e, di conseguenza, protetti), in modo da rimuovere una parte sostanziale del traffico dannoso dai punti di presenza non protetti.<\/li>\n<\/ul>\n<p>\nE un'ulteriore osservazione a questo esempio. Se una quantit\u00e0 sufficiente di traffico viene deviato attraverso gli IX, questo riduce anche la tua esposizione a tali attacchi.<\/p><\/blockquote>\n<h3>Configurazione BGP<\/h3>\n<p>\nQui ci sono due argomenti.<\/p>\n<ul>\n<li>Connettivit\u00e0<\/li>\n<li>Configurazione BGP<\/li>\n<\/ul>\n<p>\nDi connettivit\u00e0 ne abbiamo gi\u00e0 parlato un po' in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/435138\/\">parte 1<\/a><\/noindex>. Il punto \u00e8 che il traffico verso i tuoi clienti deve seguire il percorso ottimale. Tuttavia, l'ottimalit\u00e0 non riguarda sempre solo il ritardo, ma di solito il ritardo basso \u00e8 l'indicatore principale dell'ottimalit\u00e0. Per alcune aziende ci\u00f2 \u00e8 pi\u00f9 importante, per altre meno. Dipende tutto dal servizio che offri.<\/p>\n<blockquote><p><b>Esempio 1<\/b><\/p>\n<p>Se sei uno scambio e per i tuoi clienti sono importanti intervalli di tempo inferiori a un millisecondo, allora \u00e8 chiaro che non si pu\u00f2 parlare affatto di internet.<\/p><\/blockquote>\n<blockquote><p><b>Esempio 2<\/b><\/p>\n<p>Se sei un'azienda di gioco e per te sono importanti decine di millisecondi, allora, naturalmente, la connettivit\u00e0 \u00e8 molto importante per te.<\/p><\/blockquote>\n<blockquote><p><b>Esempio 3<\/b><\/p>\n<p>Bisogna anche capire che, a causa delle propriet\u00e0 del protocollo TCP, la velocit\u00e0 di trasmissione dei dati all'interno di una sessione TCP dipende anche dal RTT (Round Trip Time). Le reti CDN sono costruite anche per risolvere questo problema, portando i server di distribuzione dei contenuti pi\u00f9 vicino al consumatore di questi contenuti.<\/p><\/blockquote>\n<p> Lo studio della connettivit\u00e0 \u00e8 un tema interessante a s\u00e9 stante, meritevole di un articolo o di una serie di articoli, e richiede una buona comprensione di come \u00e8 'strutturato' internet.<\/p>\n<p>Risorse utili:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ripe.net\">ripe.net<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/bgp.he.net\">bgp.he.net<\/a><\/noindex><\/p>\n<blockquote><p><b>Esempio<\/b><\/p>\n<p>Porter\u00f2 solo un piccolo esempio.<\/p>\n<p>Supponiamo che il tuo data center si trovi a Mosca e tu abbia un solo uplink: Rostelecom (AS12389). In questo caso (single homed), BGP non ti serve, e come indirizzi pubblici probabilmente utilizzi un pool di indirizzi di Rostelecom. <\/p>\n<p>Supponiamo che tu fornisca un servizio e abbia un numero sufficiente di clienti dall'Ucraina, e che questi si lamentino di alte latenze. Indagando, hai scoperto che gli indirizzi IP di alcuni di loro si trovano nella rete 37.52.0.0\/21. <\/p>\n<p>Eseguendo un traceroute, hai visto che il traffico passa tramite AS1299 (Telia), e facendo un ping hai ottenuto un RTT medio di 70-80 millisecondi. Puoi vedere questo anche su <noindex><a rel=\"nofollow\" href=\"http:\/\/lg.ip.rt.ru\">looking glass di Rostelecom<\/a><\/noindex>.<\/p>\n<p>Utilizzando il tool whois (sul sito ripe.net o un'utilit\u00e0 locale) puoi facilmente determinare che il blocco 37.52.0.0\/21 appartiene ad AS6849 (Ukrtelecom).<\/p>\n<p>Successivamente, accedendo a <noindex><a rel=\"nofollow\" href=\"https:\/\/bgp.he.net\">bgp.he.net<\/a><\/noindex> puoi vedere che AS6849 non ha relazioni con AS12389 (non sono n\u00e9 clienti n\u00e9 uplink l'uno dell'altro, e non hanno neppure peering). Ma se guardi la <noindex><a rel=\"nofollow\" href=\"https:\/\/bgp.he.net\/AS6849#_peers\">lista dei peering<\/a><\/noindex> per AS6849, vedrai, ad esempio, AS29226 (Mastertel) e AS31133 (Megafon). <\/p>\n<p>Trovando il looking glass di questi provider, puoi confrontare il percorso e l'RTT. Ad esempio, per Mastertel l'RTT sar\u00e0 gi\u00e0 attorno ai 30 millisecondi. <\/p>\n<p>Quindi, se la differenza tra 80 e 30 millisecondi \u00e8 significativa per il tuo servizio, allora forse \u00e8 il caso di considerare la connettivit\u00e0, ottenere un numero AS in RIPE, un pool di indirizzi e connettere ulteriori uplink e\/o creare punti di presenza sugli IX.<\/p><\/blockquote>\n<p>\nUtilizzando BGP, non solo hai la possibilit\u00e0 di migliorare la connettivit\u00e0, ma anche di riservare la tua connessione a Internet.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.ssi.gouv.fr\/uploads\/2016\/03\/bgp-configuration-best-practices.pdf\">Questo documento<\/a><\/noindex> contiene raccomandazioni per la configurazione di BGP. Sebbene queste raccomandazioni siano state sviluppate sulla base delle \"best practice\" dei fornitori, esse rimangono senza dubbio utili e dovrebbero far parte del hardening di cui abbiamo discusso in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/435138\/\">prima parte<\/a><\/noindex>.<\/p>\n<h3>protezione DOS\/DDOS<\/h3>\n<p>\nAttualmente, gli attacchi DOS\/DDOS sono diventati una realt\u00e0 quotidiana per molte aziende. In effetti, in un modo o nell'altro, vieni attaccato piuttosto frequentemente. Il fatto che tu non te ne accorga dipende solo dal fatto che non \u00e8 stata organizzata un'attacco mirato contro di te, e che i mezzi di protezione di cui disponi, anche senza saperlo (diverse protezioni integrate dei sistemi operativi), sono sufficienti a minimizzare il degrado del servizio per te e i tuoi clienti.<\/p>\n<p>Esistono risorse online che, sulla base dei log delle attrezzature, disegnano in tempo reale belle mappe degli attacchi.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.csoonline.com\/article\/3217944\/security\/8-top-cyber-attack-maps-and-how-to-use-them.html\">Qui<\/a><\/noindex> Puoi trovare i link a queste.<\/p>\n<p>La mia preferita <noindex><a rel=\"nofollow\" href=\"https:\/\/threatmap.checkpoint.com\/ThreatPortal\/livemap.html\">mappa<\/a><\/noindex> di CheckPoint.<\/p>\n<p>La protezione contro DDOS\/DOS \u00e8 solitamente stratificata. Per capire perch\u00e9, \u00e8 necessario comprendere quali tipi di attacchi DOS\/DDOS esistono (vedi ad esempio, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.csoonline.com\/article\/3222095\/network-security\/ddos-explained-how-denial-of-service-attacks-are-evolving.html\">qui <\/a><\/noindex> o <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.thousandeyes.com\/three-types-ddos-attacks\/\">qui<\/a><\/noindex>)<\/p>\n<p>Cio\u00e8 abbiamo tre tipi di attacchi:<\/p>\n<ul>\n<li>attacchi volumetrici<\/li>\n<li>attacchi di protocollo<\/li>\n<li>attacchi applicativi<\/li>\n<\/ul>\n<p>\nSe per i ultimi due tipi di attacchi puoi proteggerti autonomamente utilizzando, ad esempio, dei firewall, per gli attacchi mirati a \"saturare\" i tuoi uplink non puoi proteggerti da solo (ovviamente, se la tua capacit\u00e0 complessiva delle linee internet non \u00e8 calcolata in terabit, meglio, decine di terabit).<\/p>\n<p>Pertanto, la prima linea di difesa \u00e8 la protezione contro gli attacchi \"volumetrici\" e questa protezione deve fornirla il tuo fornitore o i fornitori. Se non te ne sei ancora reso conto, allora sei semplicemente fortunato.<\/p>\n<blockquote><p><b>Esempio<\/b><\/p>\n<p>Supponiamo che tu abbia diversi uplink, ma solo uno dei fornitori possa fornirti questa protezione. Ma se tutto il traffico passer\u00e0 attraverso un solo fornitore, com'\u00e8 la connettivit\u00e0 di cui abbiamo brevemente parlato poco fa?<\/p>\n<p>Durante l'attacco dovrai in parte sacrificare la connettivit\u00e0.<\/p>\n<ul>\n<li>questo \u00e8 solo temporaneo durante l'attacco. In caso di attacco, puoi riconfigurare BGP manualmente o automaticamente in modo che il traffico passi solo attraverso il fornitore che ti fornisce \"l'ombrello\". Dopo la fine dell'attacco, puoi ripristinare il routing al suo stato originale.<\/li>\n<li>non \u00e8 necessario ridirigere tutto il traffico. Se, ad esempio, vedi che tramite alcuni uplink o peering non ci sono attacchi (o il traffico \u00e8 insignificante), puoi continuare ad annunciare i prefissi con attributi competitivi verso quei vicini BGP.<\/li>\n<\/ul>\n<\/blockquote>\n<p>\nPuoi anche delegare la protezione contro gli \"attacchi di protocollo\" e gli \"attacchi applicativi\" ai partner.<br \/>\nEcco <noindex><a rel=\"nofollow\" href=\"https:\/\/geekflare.com\/ddos-protection-service\/\">qui<\/a><\/noindex> Puoi leggere una buona ricerca (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/hosting-cafe\/blog\/324848\/\">traduzione<\/a><\/noindex>). Certo, l'articolo \u00e8 di due anni fa, ma ti dar\u00e0 una visione degli approcci su come puoi difenderti dagli attacchi DDoS.<\/p>\n<p>In linea di principio, puoi anche limitarti a questo, delegando completamente la tua protezione a terzi. Questa soluzione ha dei vantaggi, ma presenta anche un evidente svantaggio. Il fatto \u00e8 che si pu\u00f2 trattare (di nuovo, a seconda di quello che fa la tua azienda) della sopravvivenza del business. E affidare tali questioni a organizzazioni esterne\u2026<\/p>\n<p>Pertanto, vediamo come organizzare una seconda e una terza linea di difesa (come complemento alla protezione del fornitore).<\/p>\n<p>Quindi, la seconda linea di difesa \u00e8 la filtrazione e i limiti di traffico (policers) all'ingresso della tua rete. <\/p>\n<blockquote><p><b>Esempio 1<\/b><\/p>\n<p>Supponiamo che tu sia \"protetto dall'ombrello\" contro i DDoS tramite uno dei fornitori. Supponiamo che questo fornitore utilizzi Arbor per filtrare il traffico e i filtri ai confini della propria rete. <\/p>\n<p>La banda che Arbor pu\u00f2 \"gestire\" \u00e8 limitata, e il fornitore, ovviamente, non pu\u00f2 costantemente far passare il traffico di tutti i suoi partner che hanno ordinato questo servizio attraverso l'hardware filtrante. Pertanto, in condizioni normali, il traffico non viene filtrato.<\/p>\n<p>Supponiamo che ci sia un attacco SYN flood. Anche se hai ordinato un servizio in cui, in caso di attacco, il traffico viene automaticamente indirizzato al filtro, ci\u00f2 non avviene istantaneamente. Per un minuto o pi\u00f9 rimani sotto attacco. E questo pu\u00f2 portare al malfunzionamento della tua attrezzatura o alla degradazione del servizio. In questo caso, il limite di traffico sul router di confine, sebbene porti al fatto che alcune sessioni TCP non verranno stabilite durante questo tempo, salver\u00e0 la tua infrastruttura da problemi pi\u00f9 gravi.<\/p><\/blockquote>\n<blockquote><p><b>Esempio 2<\/b><\/p>\n<p>Un numero anormale di pacchetti SYN pu\u00f2 non essere solo il risultato di un attacco SYN flood. Supponiamo che fornisci un servizio in cui puoi avere simultaneamente circa 100.000 connessioni TCP (in un data center).<\/p>\n<p>Supponiamo che, a causa di un problema temporaneo con uno dei tuoi principali fornitori, met\u00e0 delle sessioni siano state 'interrotte'. Se la tua applicazione \u00e8 strutturata in modo tale che, 'senza pensarci troppo', cerca subito (o dopo un intervallo di tempo uniforme per tutte le sessioni) di ristabilire la connessione, riceverai contemporaneamente almeno 50.000 pacchetti SYN. <\/p>\n<p>Se sopra queste sessioni deve funzionare, ad esempio, un handshake ssl\/tls, che implica uno scambio di certificati, dal punto di vista dell'esaurimento delle risorse per il tuo bilanciatore di carico sar\u00e0 un 'DDOS' molto pi\u00f9 forte rispetto a un semplice SYN flood. Potrebbe sembrare che i bilanciatori dovrebbero gestire eventi di questo tipo, ma... sfortunatamente, ci siamo trovati di fronte a questo problema in pieno.<\/p>\n<p>E, naturalmente, un policer sul router di confine salver\u00e0 la tua attrezzatura in questo caso.<\/p><\/blockquote>\n<p>Il terzo livello di protezione contro DDOS\/DOS \u00e8 la configurazione del tuo firewall.<\/p>\n<p>Qui puoi contenere sia attacchi di secondo che di terzo tipo. In generale, tutto ci\u00f2 che raggiunge il firewall potr\u00e0 essere filtrato qui. <\/p>\n<blockquote><p><b>Consiglio<\/b><\/p>\n<p>Cerca di dare al firewall il minor lavoro possibile, filtrando il pi\u00f9 possibile sulle prime due linee di difesa. Ecco perch\u00e9.<\/p>\n<p>Non ti \u00e8 mai capitato di generare traffico per verificare, ad esempio, quanto sia resistente il sistema operativo dei tuoi server agli attacchi DDOS e di \"uccidere\" il tuo firewall caricandolo al 100%, utilizzando un traffico di intensit\u00e0 normale? Se no, forse \u00e8 solo perch\u00e9 non ci hai mai provato?<\/p>\n<p>In generale, il firewall, come ho gi\u00e0 detto, \u00e8 una cosa complessa, e funziona bene con vulnerabilit\u00e0 note e soluzioni testate, ma se invii qualcosa di insolito, semplicemente spazzatura o pacchetti con intestazioni errate, potresti con una certa probabilit\u00e0, non cos\u00ec piccola (basandomi sulla mia esperienza), mettere in difficolt\u00e0 anche l'hardware di alta gamma. Pertanto, nella fase 2, utilizza normali ACL (a livello L3\/L4) per consentire nella tua rete solo quel traffico che deve entrarvi.<\/p><\/blockquote>\n<h3>Filtraggio del traffico nel firewall<\/h3>\n<p>\nContinuiamo a parlare del firewall. \u00c8 importante capire che gli attacchi DOS\/DDOS sono solo una delle varianti degli attacchi informatici. <\/p>\n<p>Oltre alla protezione DAS\/DDOS possiamo avere anche qualcosa di simile al seguente elenco di funzionalit\u00e0:<\/p>\n<ul>\n<li>firewalling delle applicazioni<\/li>\n<li>prevenzione delle minacce (antivirus, anti-spyware e vulnerabilit\u00e0)<\/li>\n<li>filtraggio URL<\/li>\n<li>filtraggio dati (filtraggio dei contenuti)<\/li>\n<li>blocco file (blocco dei tipi di file)<\/li>\n<\/ul>\n<p>\nSpetta a te decidere cosa di questo elenco ti serve.<\/p>\n<p><i>Continua<\/i><br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/436230\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0447\u0435\u0442\u0432\u0435\u0440\u0442\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb. \u0421\u043e\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435 \u0432\u0441\u0435\u0445 \u0441\u0442\u0430\u0442\u0435\u0439 \u0446\u0438\u043a\u043b\u0430 \u0438 \u0441\u0441\u044b\u043b\u043a\u0438 \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0439\u0442\u0438 \u0437\u0434\u0435\u0441\u044c. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u044d\u0442\u043e\u0439 \u0433\u043b\u0430\u0432\u044b \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u043b\u0438 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0430\u0441\u043f\u0435\u043a\u0442\u044b \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u0430 \u00abData Center\u00bb. \u042d\u0442\u0430 \u0447\u0430\u0441\u0442\u044c \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u00abInternet Access\u00bb \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u0443. Internet access \u0422\u0435\u043c\u0430 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u043d\u0435\u0441\u043e\u043c\u043d\u0435\u043d\u043d\u043e \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0434\u043d\u043e\u0439 \u0438\u0437 \u043d\u0430\u0438\u0431\u043e\u043b\u0435\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 \u0442\u0435\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23032,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31057","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0447\u0435\u0442\u0432\u0435\u0440\u0442\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-vtoraya\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c. \u0413\u043b\u0430\u0432\u0430 \u0442\u0440\u0435\u0442\u044c\u044f. \u0421\u0435\u0442\u0435\u0432\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c. \u0427\u0430\u0441\u0442\u044c \u0432\u0442\u043e\u0440\u0430\u044f | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0447\u0435\u0442\u0432\u0435\u0440\u0442\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-vtoraya\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:39:12+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:39:12+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Come prendere il controllo della propria infrastruttura di rete. Capitolo tre. Sicurezza della rete. Parte seconda | ProHoster","description":"Questo articolo \u00e8 il quarto di un ciclo di articoli su \"Come prendere il controllo della propria infrastruttura di rete\".","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-vtoraya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c. \u0413\u043b\u0430\u0432\u0430 \u0442\u0440\u0435\u0442\u044c\u044f. \u0421\u0435\u0442\u0435\u0432\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c. \u0427\u0430\u0441\u0442\u044c \u0432\u0442\u043e\u0440\u0430\u044f | ProHoster","og:description":"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0447\u0435\u0442\u0432\u0435\u0440\u0442\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-vtoraya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:39:12+00:00","article:modified_time":"2019-10-31T18:39:12+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31057","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 04:19:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:24:14","updated":"2026-01-21 04:19:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31057","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=31057"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31057\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/23032"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=31057"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=31057"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=31057"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}