Come può un amministratore proteggersi da 0 giorni prima che le patch siano disponibili?

Sjoerd

2018-12-13 14:43:00 UTC

view on stackexchange narkive permalink

La persona che scopre un problema di sicurezza spesso lo segnala prima al fornitore del software o allo sviluppatore. Questo dà al fornitore del software il tempo di risolvere il problema prima della pubblicazione. Quindi, dopo che è stato risolto, il bug viene divulgato pubblicamente. Questo processo è chiamato divulgazione responsabile.

A volte, qualcuno non rivela lo zero-day al fornitore di software ma lo usa per hackerare altri sistemi. In questo modo si possono avvisare le società di sicurezza e divulgare il bug, bruciando lo zero-day.

Non credo che la tua dichiarazione "la maggior parte delle volte, 0day è usato per mesi dai cappelli neri " è vero. Questo è vero per alcuni problemi di sicurezza, ma molti bug zero-day vengono rilevati per la prima volta da hacker white-hat. Non direi che gli hacker black hat siano davanti agli hacker white hat. Entrambi riscontrano problemi di sicurezza e alcuni di questi si sovrappongono. Tuttavia, l'attacco è più facile della difesa in quanto l'attacco deve trovare solo un bug e la difesa deve correggere tutti i bug.

Grazie per la risposta, ho detto che: "la maggior parte delle volte, questo stesso 0day è usato da mesi dai cappelli neri" perché ho letto molte interviste sui cappelli neri dicendo che stanno usando quegli 0 giorni prima di qualsiasi pubblicazione

@pjc50 È assolutamente vero che i cappelli neri usano 0 giorni mesi (o anni) prima di essere patchati.

Apparentemente i giorni zero _possono_ avere una vita molto lunga;il documento a cui si fa riferimento in questa presentazione afferma che i giorni zero hanno un'aspettativa di vita media di quasi 7 anni: https://www.youtube.com/watch?v=8BMULyCiSK4

@You: Prenderei quel numero con un granello di sale.Proprio come quasi tutti i bug del software, la maggior parte dei problemi di sicurezza che altrimenti sarebbero qualificati come 0day sono spesso risolti ore o giorni dopo che detto bug è stato introdotto in una versione rilasciata del software, di solito senza troppe fanfare, ma questi non fanno mai notizia (o sicurezzatracker) perché non interessano molte persone.I 0 giorni che tendono a fare notizia sono quelli che vivono più a lungo, quindi c'è un enorme bias di selezione.

@LieRyan: Assolutamente, e lo dicono molto nella presentazione (perché la dimensione del campione è piuttosto piccola, le definizioni possono variare, ecc.) - ma sono ancora più dati rispetto all'affermazione puramente speculativa nella risposta.

@You: IMO, è un numero senza senso e fuorviante.Si basa sul campione di convenienza di qualunque bug faccia notizia e come prevediamo l'età dei bug scenderà rapidamente man mano che aumenti la dimensione del campione.Non sembra una statistica significativa poiché il numero non converge.Puoi semplicemente scegliere quasi tutti i numeri che desideri selezionando dove interrompere l'aggiunta al campione.

@You 7 anni fino al rilascio di una patch o alla maggior parte dei sistemi?Presumibilmente quest'ultimo.Ho difficoltà a credere che i cappelli neri possano mantenere segreto un exploit 0-day funzionante dal resto del mondo per 7 anni, soprattutto perché molti cappelli bianchi / grigi attraverserebbero gli stessi canali dei cappelli neri.

@NiklasHolm È il tempo che intercorre tra la scoperta iniziale e il rilevamento da parte di terzi (~ 31 minuti dall'inizio della conversazione).

Questo è principalmente un commento.Non risponde alla domanda.

forest

2018-12-13 16:16:41 UTC

view on stackexchange narkive permalink

Quando viene pubblicato uno 0day, come può un amministratore proteggere la sua applicazione / sito web tra il momento in cui lo 0day viene pubblicato e lo sviluppo della patch?

Usano soluzioni temporanee fino al rilascio di una patch.

Quando viene fuori la notizia di uno 0day, spesso vengono pubblicate varie soluzioni alternative che rompono l'exploit eliminando alcuni prerequisiti per abusare della vulnerabilità. Ci sono molte possibilità:

La modifica di un'impostazione di configurazione può disabilitare la funzionalità vulnerabile.
La disattivazione dei servizi vulnerabili, quando pratico, può prevenire lo sfruttamento.
L'attivazione di misure di sicurezza non predefinite potrebbe interrompere l'exploit.

Ogni bug è diverso e ogni la mitigazione è diversa. Un amministratore con una buona conoscenza della sicurezza può trovare soluzioni alternative se vengono rilasciati dettagli sufficienti sulla vulnerabilità. La maggior parte degli amministratori, tuttavia, guarderà agli avvisi sulla sicurezza pubblicati dal fornitore del software.

A volte, un amministratore non deve fare nulla . Questo può essere il caso se la vulnerabilità interessa solo una configurazione non predefinita o una configurazione che non è impostata sui loro sistemi. Ad esempio, una vulnerabilità nel sottosistema video DRM per Linux non deve preoccupare un amministratore di sistema con uno stack LAMP, poiché i suoi server non useranno comunque DRM. Una vulnerabilità in Apache, d'altra parte, potrebbe essere qualcosa di cui dovrebbero preoccuparsi. Un buon amministratore di sistema sa cos'è e non è un fattore di rischio.

Inoltre, la maggior parte delle volte, questo stesso 0day viene utilizzato per mesi dai blackhat, quindi i blackhat sono davanti ai whitehats?

I cappelli bianchi sono più sofisticati, ma i cappelli neri sono più efficienti.

Se i blackhat siano o meno davanti ai whitehat è una domanda molto soggettiva. Blackhats userà qualunque cosa funzioni. Ciò significa che i loro exploit sono efficaci, ma sporchi e, a volte, non sofisticati. Ad esempio, mentre è possibile scoprire il layout ASLR di un browser tramite attacchi di canale laterale, questo non è realmente utilizzato in natura poiché esistono già bypass ASLR onnipresenti e non sofisticati. Whitehats d'altra parte ha bisogno di pensare a soluzioni e effettivamente convincere il fornitore di software a prendere sul serio il rapporto. Ciò non influisce quasi nella stessa misura sui blackhat, poiché spesso possono iniziare a trarre vantaggio dalla loro scoperta nel momento in cui lo fanno. Non hanno bisogno di aspettare una terza parte.

Dalla mia esperienza, i blackhat hanno spesso un vantaggio significativo. Ciò è principalmente dovuto al fatto che la cultura attuale tra i cappelli bianchi è quella di cacciare e schiacciare i singoli insetti. Meno enfasi viene posta sull'eliminazione di intere classi di bug e, quando lo è, vengono create mitigazioni sub-par e over-hyped (come KASLR). Ciò significa che i blackhat possono pompare 0 giorni più velocemente di quanto possano essere riparati, poiché viene prestata così poca attenzione alla superficie di attacco e ai vettori di sfruttamento che continuano ad essere utilizzati e riutilizzati.

Un'altra importante differenza è che i whitehat spesso devono convincere il fornitore del software a risolvere il problema e trovare una tecnica di correzione / mitigazione.I blackhats non devono preoccuparsene.

@LieRyan Ottimo punto!Questo è molto vero.

Se posso aggiungere la soluzione temporanea più efficace: spegni i server.Trovo utile ricordare che questa è una soluzione alternativa che rende il server (quasi) perfettamente sicuro perché porta immediatamente alla discussione di sicurezza vs usabilità, che è una discussione molto importante quando si applicano soluzioni alternative più ragionevoli (come quelle che hai elencato).Se l'equilibrio tra sicurezza e usabilità è intuitivo, è quasi inutile tirare fuori questa sciocca soluzione alternativa, ma se non è intuitivo per qualcuno, potrebbe provocare il pensiero.

schroeder

2018-12-13 16:08:07 UTC

view on stackexchange narkive permalink

Quando uno zero-day viene rilasciato o pubblicato, viene fornito con più di un semplice nome e icona di fantasia. Ci sono dettagli su come lo zero-day viene utilizzato per sfruttare il sistema. Questi dettagli costituiscono la base della risposta del difensore, incluso il modo in cui la patch deve essere progettata.

Ad esempio, con WannaCry / EternalBlue, la vulnerabilità è stata trovata dalla NSA e hanno tenuto la conoscenza per sé (lo stesso accade nella comunità criminale dove le vulnerabilità possono essere scambiate mercato nero). Sono trapelati i dettagli, che hanno informato Microsoft su come creare la patch e ha anche informato gli amministratori su come difendersi da essa: disabilitare SMBv1 o almeno bloccare la porta SMB da Internet.

È così che gli amministratori si proteggono. L'applicazione di patch è solo una parte della "gestione delle vulnerabilità". Ci sono molte cose che un amministratore può fare per gestire le vulnerabilità anche se non può o non vuole applicare la patch.

Nel caso WannaCry, l'NHS non ha applicato patch, ma non ha nemmeno impiegato le altre difese che si sarebbero protette da sole.

Una parte importante del mio lavoro è progettare mitigazioni della vulnerabilità per sistemi a cui non è possibile applicare patch per vari motivi aziendali. L'applicazione di patch è la soluzione migliore, in generale, ma a volte semplicemente non è possibile al momento della patch.

... i blackhat sono davanti ai whitehat?

Questo pone un problema interessante. Se un blackhat trova un problema e lo condivide solo con altri blackhat (o altri membri della comunità dell'intelligence), significa che i blackhat, complessivamente , sono in vantaggio sui whitehats? Sì. Una volta che uno zero-day viene esposto, perde il suo potere (questo è il punto centrale per rivelarlo). Quindi, mantenerlo segreto, gli dà potere.

I blackhat sono più abili o usano tecniche migliori dei whitehat? No. Ma i segreti condivisi conferiscono ai blackhats più potere, complessivamente.

Non sono d'accordo sul fatto che i segreti condivisi diano ai blackhat più potere in aggregato.Mentre c'è scambio di informazioni nel sottosuolo, è altamente localizzato.Credo che sia la cultura che dà la priorità alla caccia ai bug (al contrario della ricerca sulla mitigazione) che dà un vantaggio ai blackhat.Puoi correggere un bug che ho usato per sfruttare ROP, ma la tua mancanza di CFI efficace e onnipresente significa che ne troverò un altro in pochissimo tempo.

Il fatto che l'utilità di uno zero-day sia in gran parte legata al tempo in cui rimane un segreto fa parte dell'argomento principale a favore della politica di Full Disclosure, vs Responsible / Coordinated Disclosure: https://en.wikipedia.org/wiki / Full_disclosure_ (computer_security) Full Disclosure a tutti brucia efficacemente lo zero-day immediatamente

@ChrisFernandez La divulgazione completa è utile quando il fornitore del software non esegue aggiornamenti tempestivi e non ascolta i ricercatori sulla sicurezza.In tal caso, la divulgazione completa consente agli utenti di difendersi con soluzioni alternative.Quando il fornitore è reattivo e si preoccupa effettivamente della sicurezza, la divulgazione responsabile potrebbe essere migliore, poiché non si siederà sul bug per anni.

La completa divulgazione ucciderà i fornitori che non rispondono e che non rispondono.Se utilizzata da molto tempo, la divulgazione completa avrebbe eliminato la maggior parte dei fornitori che pensano di poter eseguire il controllo di qualità dopo aver introdotto sul mercato un software.Questo è il modo in cui vengono eliminati i cattivi attori di qualsiasi altro settore industriale.

Philipp

2018-12-13 16:10:12 UTC

view on stackexchange narkive permalink

Quando viene pubblicato uno 0day, come può un whitehat proteggere la sua applicazione / sito web tra il momento in cui lo 0day viene pubblicato e lo sviluppo della patch?

A volte ci sono soluzioni alternative che risolvere o mitigare il problema.

A volte è possibile disabilitare alcune funzionalità o modificare alcune impostazioni nel software che fanno sì che l'exploit non funzioni più. Ad esempio, l'infezione con il Morris Worm del 1988 potrebbe essere prevenuta creando una directory / usr / tmp / sh . Questo ha confuso il worm e gli ha impedito di funzionare.
A volte l'exploit richiede un qualche tipo di interazione da parte dell'utente. In tal caso puoi avvisare gli utenti di non farlo. (" Non aprire le email con oggetto ILOVEYOU"). Ma poiché gli esseri umani sono umani, di solito questa soluzione non è molto affidabile.
A volte l'attacco è facile da identificare sulla rete, quindi puoi bloccarlo con qualche regola del firewall più o meno complicata. Il virus Conficker, ad esempio, mirava a una vulnerabilità nel servizio di chiamata a procedura remota di Windows. Di solito non c'è alcun motivo per cui questa funzionalità sia accessibile dall'esterno della rete locale, quindi era possibile proteggere un'intera rete semplicemente bloccando le richieste esterne alla porta 445 TCP.
A volte è possibile sostituire il software vulnerabile con un'alternativa. Ad esempio, la nostra organizzazione installa due diversi browser Web su tutti i client Windows. Quando uno di loro ha una vulnerabilità nota, gli amministratori possono disattivarlo tramite criteri di gruppo e dire agli utenti di utilizzare l'altro fino al rilascio della patch.
Come ultima risorsa, puoi semplicemente staccare la spina sui sistemi vulnerabili. Se i sistemi non disponibili causano più o meno danni rispetto a quelli online e aperti agli exploit è una considerazione aziendale che devi valutare in ogni singolo caso.

Ma a volte nessuna di queste è un'opzione praticabile. In tal caso puoi solo sperare che ci sarà presto una patch.

Inoltre, la maggior parte delle volte, questo stesso 0day viene utilizzato per mesi dai blackhat, quindi i blackhat sono davanti ai whitehat?

Accade abbastanza frequentemente che sviluppatori / whitehats scoprano una possibile vulnerabilità di sicurezza nel loro software e la correggano prima che venga sfruttata. Il primo passaggio della divulgazione responsabile è informare gli sviluppatori in modo che possano correggere la vulnerabilità prima di pubblicarla.

Ma di solito non si sente parlare di questo nei media. Quando il punto 59 delle note sulla patch per SomeTool 1.3.9.53 legge "risolto un possibile overflow del buffer durante l'elaborazione di file foobar malformati" di solito non è particolarmente interessante.

Credo che il tuo esempio di verme Morris sia scadente.Il worm Morris utilizzava diverse vulnerabilità per passare da un sistema all'altro e infettarle, una delle quali era il difetto fingerd.(C'era anche almeno la modalità di debug di sendmail e le password degli account utente comuni.) Se ricordo bene, il vero trucco per disinnescare quella era `mkdir / tmp / sh`.

Un buon punto di vista sul fatto che spegnere la macchina a volte è una decisione aziendale ragionevole.

cybernard

2018-12-15 21:52:14 UTC

view on stackexchange narkive permalink

Un'altra difesa fondamentale è il monitoraggio e la conoscenza del sistema.

Dove sono i tuoi segreti preziosi e chi ha accesso ad essi.

Se qualcuno cerca di connettersi al tuo server di posta sulla porta 80, bandiera rossa.

Perché il server di posta, all'improvviso, invia traffico a un IP insolito.

Il server di posta ora ha 10 volte il traffico perché?

Monitora le persone che si connettono agli indirizzi IP esterni. Elimina e / o blocca tutte le porte e i protocolli esterni che non sono in uso.

Nessun utente legittimo si connetterà al tuo server web su altro che 80 o 443. A meno che tu non abbia aggiunto servizi aggiuntivi. Potresti considerare di bloccare questi IP per un po 'di tempo. A volte, l'IP fa parte di pool dinamici e non puoi sempre risolvere un problema con una lista nera, quindi devi semplicemente rilasciare i pacchetti.

Se la tua azienda fa affari solo in 1 paese, forse dovresti semplicemente bloccare tutti gli altri paesi.

È possibile utilizzare whois per trovare il proprietario globale dell'intervallo di indirizzi IP e, se presente, utilizzare le informazioni di contatto dell'amministratore per avvisare il proprietario. Possono rintracciarlo alla loro fine. (Vale la pena provare)

Dovresti ricevere una notifica quando un sistema viene contattato da un altro sistema in modo imprevisto. Dopo il primo potresti ricevere un sacco di notifiche, ma se i computer sono sulla tua rete, puoi indagare su entrambi i lati. Quindi eliminalo o inseriscilo nella lista bianca come previsto per il traffico.

Questi strumenti di monitoraggio ti informeranno anche sulle scansioni delle porte, a meno che tu non abbia un team di sicurezza autorizzato, nessun altro dovrebbe eseguire la scansione delle porte.

Guarda per eventi regolari e se si fermano misteriosamente perché?

Controlla la macchina per le infezioni. Se i servizi sono disabilitati, dovresti essere avvisato in anticipo in modo che le modifiche siano previste e non misteriose.

Blocca il più possibile e controlla il resto.

Ora, una volta che hai un attacco, devi fare qualcosa al riguardo.

A volte spegnere temporaneamente il sistema è l'unica opzione. Forse hai bisogno di bloccare il loro indirizzo IP per un po '.

Devi ancora proteggere e monitorare tutti i tuoi servizi legittimi.

Oltre a monitorare la comunità per gli annunci di vulnerabilità. Dovresti avere dei penetration tester per trovare i bug in anticipo prima degli hacker. Quindi hai la possibilità di mitigare l'attacco alle tue condizioni. Notificare il manutentore del sistema di effetti in modo che possano correggerlo. Se è open source, puoi chiedere a qualcuno di correggerlo.

I sistemi di rilevamento delle intrusioni e snort possono anche esaminare e potenzialmente bloccare gli hack in arrivo rilevando modelli sospetti.

per trovare un prodotto alternativo per sostituire quello vulnerabile a seconda della gravità del problema.

Come sempre mantenere aggiornato il tuo software aiuta a proteggerti.

In questo modo puoi bloccare attività sospetta, finché non si determina la sua legittimità.

user99573

2018-12-15 17:12:15 UTC

view on stackexchange narkive permalink

La maggior parte dei potenziali exploit richiede una catena di vulnerabilità per essere eseguita. Leggendo lo zero-day non ancora corretto, è ancora possibile identificare altre vulnerabilità o pre-condizioni che lo zero-day richiederebbe.

Per difendersi dalla minaccia di (diciamo) un attacco RDP dall'esterno rete (errore di autenticazione RDP zero-day pubblicato), non consentire RDP da off-site. Se non hai davvero bisogno di RDP dall'esterno, questa è un'opportunità per correggere una svista. Oppure, se è necessario disporre di RDP da off-site, forse è possibile identificare una whitelist di IP da cui consentire queste connessioni e restringere l'apertura nel firewall.

Allo stesso modo, per difendersi da una minaccia RDP interna (e in una certa misura esterna), limitare la capacità degli utenti A) di eseguire RDP, B) macchine di eseguire RDP, C) la rete di passare RDP, D) macchine per accettare RDP, E) utenti per consentire RDP. Quali VLAN dovrebbero avere la capacità di generare RDP in uscita? Quali macchine dovrebbero essere in grado di farlo? E così via.

Ognuno di questi passaggi, sia negli scenari esterni che in quelli interni, lavora per rafforzare la tua rete contro un exploit di autenticazione RDP anche senza una patch.

Una mentalità di difesa in profondità consente di interrompere la catena di vulnerabilità / condizioni necessarie per contrastare anche uno zero-day senza patch. A volte.

Ho scelto intenzionalmente un problema abbastanza semplice qui solo per illustrare il punto.

Fonte: l'ho già fatto.

Tyler Durden

2018-12-17 14:20:18 UTC

view on stackexchange narkive permalink

Relativamente pochi hack consentono all'aggressore di penetrare in un sistema. La maggior parte sono bug di "escalation dei privilegi" che consentono a un utente malintenzionato di avere un maggiore controllo sul sistema dopo avervi accesso. Ci sono così tanti modi per ottenere il controllo amministrativo di una macchina una volta che un hacker vi ha accesso, che è più o meno una perdita di tempo cercare di proteggere una macchina dall'escalation dei privilegi. La tua migliore politica è di concentrarti sull'impedire agli hacker di entrare in primo luogo e monitorare la tua rete per le intrusioni.

Quasi tutte le intrusioni provengono da soli tre metodi. Vuoi spendere tutte le tue risorse di difesa informatica disponibili per difenderti da questi. Sono:

(1) Email di phishing contenenti PDF o PPT avvelenati. Ci sono tonnellate di zero giorni che prendono di mira PDF e PPT, e la natura di entrambi questi formati di applicazioni è tale che non c'è più o meno modo di proteggersi da un trojan contemporaneo in nessuno dei due. Pertanto, hai fondamentalmente due opzioni: richiedere che tutti gli allegati PDF / PPT siano sottoposti a un processo di verifica, che non è pratico per la maggior parte delle organizzazioni, o per addestrare i tuoi dipendenti a controllare le e-mail da soli, che è l'opzione migliore nella maggior parte dei casi. Una terza opzione è testare tutti i PDF e i PPT inviati all'organizzazione in un ambiente sandbox dopo il fatto, ma questo è possibile solo per le organizzazioni avanzate, come i militari, non per l'azienda media. L'opzione 3 ovviamente non impedisce l'intrusione, ma ti avvisa immediatamente se si verifica.

(2) Vulnerabilità del browser. La stragrande maggioranza degli exploit basati su browser prende di mira Internet Explorer, quindi puoi difenderne probabilmente il 95% semplicemente impedendo agli utenti di utilizzare IE e richiedendo loro di utilizzare Chrome o Firefox. Puoi prevenire il 99% degli exploit basati su browser richiedendo agli utenti di utilizzare NoScript e addestrandoli al suo utilizzo, il che purtroppo non è pratico per la maggior parte delle organizzazioni.

(3) Vulnerabilità del server. Un esempio potrebbe essere il bug NTP di qualche anno fa. Puoi difenderti ampiamente da questi assicurandoti che tutti i server aziendali siano in esecuzione su reti isolate (una "zona demilitarizzata") e che quei server siano stretti e non eseguano servizi non necessari. In particolare, vuoi assicurarti che tutti i server Web aziendali vengano eseguiti da soli in ambienti isolati e che nulla possa entrare o uscire da tali ambienti senza che un essere umano esegua esplicitamente la copia in modo controllato.

Ovviamente ci sono molti exploit che non rientrano in queste categorie, ma è meglio dedicare il tuo tempo ad affrontare le tre classi di vulnerabilità elencate sopra.

user50312

2018-12-14 07:30:27 UTC

view on stackexchange narkive permalink

Bene, va bene avere 0 giorni da un utente malintenzionato, il problema è quanti zero giorni hanno e quanto costa bruciare tutti gli 0 giorni nella tua rete.

Se non disponi di patch aggiornate, riduce il costo per un attaccante per sviluppare una kill chain.

Quando ci pensi, come invieresti ad attaccare una rete? Supponiamo che tu inizi con un attacco di phishing / waterhole.

Se si tratta di un attacco waterhole, potrebbe essere necessario trovare un giorno 0 in flash che consente di eseguire codice nel browser, quindi potrebbe essere necessario uscire prima dalla sandbox del browser, che richiede un altro 0 giorno. E poi potresti dover affrontare appcontainer, che richiede un altro exploit per raggiungere i privilegi a livello di sistema operativo. E ci sono meccanismi di protezione come SIP in macOS, significa che anche se hai accesso root, non puoi accedere alla memoria importante. Ciò significa che hai bisogno di un altro exploit del kernel 0day. Se sta eseguendo Windows 10 con cred guard e stai prendendo di mira Lsass.exe, potresti aver bisogno di un altro giorno 0 per attaccare l'hypervisor.

Quindi si scopre che l'attacco è molto costoso e richiede molti sforzi di ricerca, e nel frattempo mentre li sfrutti, potresti attivare un avviso di sicurezza.

Quindi, come difensore, assicurati di conoscere bene la tua rete, avere controlli di difesa in ogni singolo livello e dovresti essere in grado di difenderti dagli attacchi 0 giorni.

`` Bene, va bene avere 0 giorni da un attaccante, il problema è quanti zero giorni hanno e quanto costa loro bruciare tutti gli 0 giorni nella tua rete. '' Voglio dire, non lo è davverova bene avere vulnerabilità di 0 giorni se questo è ciò che stai suggerendo, ma sì, ogni codice scritto contiene bug e dovrebbero essere corretti.Avere delle vulnerabilità non va bene e dovrebbero essere corrette, anche se abusarne è costoso.

@KevinVoorn YEa d'accordo, ecco perché ho detto "Se non hai le patch aggiornate, riduce il costo per un attaccante sviluppare una kill chain". L'applicazione delle patch è ancora molto importante, non puoi impedire a qualcuno di avere 0day

WoJ

2018-12-15 21:07:16 UTC

view on stackexchange narkive permalink

Il problema non è solo con zero giorni. Ci sono molte aziende che continuano a trascinare patch di 200 giorni per una moltitudine di motivi (alcuni buoni, altri cattivi).

Hai un lungo elenco di soluzioni, un altro è usare virtuale patching. Di solito crea una mitigazione del problema prima che raggiunga il servizio (l'ho imparato anni fa grazie a un prodotto Trend Micro - nessun collegamento con loro ma l'ho testato e per lo più ha funzionato).