CVE-2026-98432 - Problema relativo all’use-after-free del kernel Linux IPv4 TCP
ID Bollettino: 2026-160-AWS
Ambito: AWS
Tipo di contenuto: Importante (richiede attenzione)
Data di pubblicazione: 30/10/2026 22:15 PDT
Data ultimo aggiornamento: 11/10/2026 13:45 PST
Riepilogo:
AWS è a conoscenza del CVE-2026-98432, un problema di memoria nel percorso di handshake TCP IPv4 del kernel Linux che riguarda le versioni 4.4 e successive del kernel. In condizioni specifiche, una terza parte remota e non autenticata può inviare pacchetti TCP IPv4 predefiniti contenenti opzioni IP a un listener interessato. Ciò si traduce in un crash del kernel, nella divulgazione della memoria del kernel o in un danneggiamento della memoria. I ricercatori hanno dimostrato l’esecuzione di codice remoto non autenticato su host con un listener Multipath TCP (MPTCP). Al momento non abbiamo prove che questo problema sia stata sfruttato. Aggiorneremo questo bollettino non appena saranno disponibili ulteriori informazioni.
Stato attuale della mitigazione:
Amazon Linux
Sono disponibili i pacchetti kernel Amazon Linux 2 e Amazon Linux 2023 per la risoluzione del CVE-2026-98432. I clienti devono aggiornare i pacchetti del kernel e riavviare. Versioni del kernel kernel-4.14, kernel-5.4, kernel-5.10, kernel-5.15, kernel-6.1, kernel-6.12 e kernel-6.18: Disponibile da subito.
Avvisi: ALIAS 2-2026-4065, ALAS2 KERNEL -5.4-2026-135, ALAS2 KERNEL -5.10-2026-137, ALAS2 KERNEL -5.15-2026-120, AHIMÈ 2023-2026-3365, AHIMÈ 2023-2026-3335, AHIMÈ 2023-2026-3251.
Per aggiornare:
|
# Amazon Linux 2 # Amazon Linux 2023 Kernel 6.1 # Amazon Linux 2023 Kernel 6.12 # Amazon Linux 2023 Kernel 6.18 |
Le istanze di Amazon Linux 2023 bloccate su una versione di rilascio devono utilizzare la release 2023.12.20261102 o successiva per ricevere il kernel aggiornato.
Amazon EC2
I clienti che eseguono istanze Linux autogestite su Amazon EC2 sono responsabili dell’aggiornamento del kernel su tali istanze. I clienti che utilizzano Amazon Linux devono aggiornare il pacchetto del kernel come descritto sopra. I clienti che utilizzano un’altra distribuzione Linux devono seguire le indicazioni della propria distribuzione per applicare la correzione non appena sarà disponibile.
Dopo aver aggiornato il kernel, sarà necessario riavviare per rendere effettiva la correzione. L’aggiornamento e il riavvio del kernel sono l’unica soluzione completa a questo problema.
AWS Web Application Firewall, Application Load Balancer, Classic Load Balancer, Listener TLS su Network Load Balancer, Amazon CloudFront, Gateway Amazon API
I clienti che utilizzano i servizi di cui sopra non ricevono connessioni TCP direttamente da origini non attendibili se seguono le best practice. AWS sta applicando aggiornamenti all’infrastruttura sottostante di questi servizi e non è richiesta alcuna azione immediata da parte del cliente se si utilizzano questi servizi. Consigliamo comunque ai clienti di aggiornare le istanze autogestite dietro questi servizi entro i prossimi 30 giorni.
AWS Global Accelerator
Global Accelerator non supporta le opzioni IP sui pacchetti TCP IPv4. Tutti i pacchetti in entrata contenenti opzioni IP vengono eliminati dal piano dati di Global Accelerator prima dell’elaborazione di qualsiasi connessione. Pertanto, il piano dati di Global Accelerator stesso e tutti gli endpoint dietro Global Accelerator non sono interessati da questo problema.
Amazon EKS
Il piano di controllo Kubernetes gestito da Amazon EKS è stato aggiornato per risolvere questo problema. Non è richiesta alcuna azione da parte del cliente per il piano di controllo EKS.
Amazon EKS ha rilasciato delle AMI Amazon Linux 2023 aggiornate e ottimizzate per EKS (versione v20261031) che risolvono questo problema. I clienti che utilizzano gruppi di nodi gestiti, nodi autogestiti o Karpenter con queste AMI devono aggiornare i propri nodi alla versione v20261031 o successiva.
Amazon EKS ha rilasciato le AMI EKS Auto Mode aggiornate il 31 ottobre 2026. EKS Auto Mode sostituisce automaticamente i nodi esistenti con nodi che eseguono l’AMI aggiornata, in base ai budget di interruzione di NodePool. Non è richiesta alcuna azione da parte del cliente per EKS Auto Mode. Le AMI EKS Auto Mode sono denominate nel formato "Bottlerocket (EKS Auto, Standard) 2026.10.31". Per verificare quale AMI sono in esecuzione i tuoi nodi, esegui il comando `kubectl get node -o wide` e confronta la colonna OS-IMAGE.
I pod Amazon EKS Fargate avviati dopo il 1 novembre 2026, alle 9:00 PST (1 novembre 2026, 17:00 UTC) vengono eseguiti sulla piattaforma con patch. Amazon EKS sostituisce i pod già in esecuzione entro 14 giorni come parte della nostra routine ciclo di patching.
Cache elastica
Stiamo implementando soluzioni di mitigazione in tutto il mondo per prevenire lo sfruttamento delle tue cache. La soluzione a lungo termine consisterà nell'applicare un aggiornamento self-service ai cluster ElastiCache denominati elasticache-20261106-arm o elasticache-20261106-intel, che ora sono disponibili.
MemoriaDB
Stiamo implementando soluzioni di mitigazione in tutto il mondo per prevenire lo sfruttamento dei tuoi database. La soluzione a lungo termine consisterà nell'applicare un aggiornamento self-service ai cluster MemoryDB denominati memorydb-20261106-arm, che ora sono disponibili.
AWS RTB Fabric
I gateway RTB Fabric terminano le connessioni TCP in entrata e aprono connessioni separate agli endpoint dei clienti, quindi i pacchetti IPv4 contenenti opzioni IP non vengono trasmessi agli endpoint che ricevono traffico da RTB Fabric. AWS ha completato gli aggiornamenti all'infrastruttura sottostante di RTB Fabric e per RTB Fabric non è richiesta alcuna azione da parte del cliente. I clienti che utilizzano istanze Linux autogestite, inclusi gli endpoint che inviano o ricevono traffico tramite RTB Fabric, sono responsabili dell'aggiornamento del kernel su tali istanze come descritto sopra per Amazon EC2.
AWS Elastic Beanstalk
Le piattaforme Elastic Beanstalk basate su Amazon Linux 2023 utilizzano le versioni del kernel interessate. Le piattaforme Elastic Beanstalk Windows Server non sono interessate.
Elastic Beanstalk ha rilasciato versioni della piattaforma Amazon Linux 2023 che includono il kernel con patch. Queste versioni della piattaforma sono state rilasciate il 4 novembre 2026 e utilizzano la versione AMI 2023.12.20261102. Per i dettagli, consulta la Note sulla versione di Elastic Beanstalk. Gli ambienti con aggiornamenti gestiti della piattaforma hanno consentito l'aggiornamento alla versione patchata durante la successiva finestra di manutenzione. Per altri ambienti, aggiornare la versione della piattaforma.
Se non riesci ad aggiornare subito la versione della tua piattaforma, aggiorna il kernel sulle istanze del tuo ambiente e riavvia, come descritto nella precedente sezione Amazon Linux. Le istanze che Elastic Beanstalk avvia in seguito, ad esempio durante il dimensionamento in aumento (scale out) o la sostituzione di un’istanza, vengono avviate a partire dall’AMI della piattaforma. Necessitano dello stesso aggiornamento fino a quando l’ambiente non esegue la versione della piattaforma con patch.
Amazon ECS
I clienti che eseguono ECS su EC2 devono aggiornare il kernel sulle proprie istanze container e riavviarle, oppure sostituirle con istanze lanciate dall'ultima AMI ottimizzata per ECS (versione 20261031).
Fargate: AWS ha rilasciato una versione della piattaforma con patch. Tutte le nuove attività avviate dopo il 1 novembre 2026, alle 9:00 PST (1 novembre 2026, 17:00 UTC) utilizzano la versione della piattaforma con patch. Le attività esistenti vengono ritirate in base alle impostazioni di ritiro delle attività, oppure è possibile sostituirle prima, come descritto in Ritiro e manutenzione delle attività per AWS Fargate.
Istanze gestite ECS: AWS ha rilasciato un'AMI aggiornata e le nuove istanze lanciate contemporaneamente utilizzano l'AMI patchata. Le istanze esistenti vengono esaurite 14 giorni dopo il lancio o prima per allinearsi alle finestre degli eventi (Applicazione di patch nelle istanze gestite di Amazon ECS). Per aggiornarli immediatamente, scaricali manualmente.
Bottlerocket
Il kernel Bottlerocket con patch è stato rilasciato. AMI Bottlerocket aggiornate bottlerocket v1.68.1 con il kernel patchato sono stati rilasciati il 31/10.
AWS Lambda
I carichi di lavoro Lambda non sono interessati da questo problema. CVE-2026-98432 richiede che un attore invii un pacchetto di rete appositamente predisposto a una porta TCP IPv4 raggiungibile pubblicamente su un host interessato. Le funzioni Lambda non dispongono di porte TCP IPv4 pubbliche, quindi non esiste un percorso che consenta a una parte esterna di raggiungere l'ambiente di esecuzione della funzione con il tipo di traffico necessario per attivare questo problema. Non è richiesta alcuna azione da parte del cliente.
Come misura di difesa in profondità, stiamo applicando in modo proattivo la patch del kernel all’infrastruttura del servizio Lambda.
Amazon Lightsail
I clienti che eseguono istanze Linux autogestite su Amazon Lightsail sono responsabili dell’aggiornamento del kernel su tali istanze. I clienti che utilizzano Amazon Linux devono aggiornare il pacchetto del kernel come descritto sopra. I clienti che utilizzano un’altra distribuzione Linux devono seguire le indicazioni della propria distribuzione per applicare la correzione non appena sarà disponibile.
Dopo aver aggiornato il kernel, sarà necessario riavviare per rendere effettiva la correzione. L’aggiornamento e il riavvio del kernel sono l’unica soluzione completa a questo problema.
Endpoint VPC (PrivateLink)
I clienti che eseguono target Linux dietro i servizi endpoint AWS PrivateLink devono aggiornare il kernel su tali target e riavviarli, oppure applicare i passaggi provvisori seguenti finché non possono.
VPC Lattice
I clienti che eseguono target di livello 4 (TCP) su Linux con VPC Lattice devono aggiornare il kernel su tali target e riavviarli, oppure applicare i passaggi provvisori indicati di seguito finché non possono.
RDS/Aurora
I clienti RDS/Aurora devono verificare che le porte del loro database non siano accessibili da Internet. Inoltre, abbiamo implementato una soluzione completa a livello mondiale per risolvere questo problema sui vostri host di database. La soluzione a lungo termine consisterà nell’applicare patch al sistema operativo del database. Questa patch è ora disponibile per essere applicata.
Neptune
I clienti Neptune devono verificare che le porte del loro database non siano accessibili da Internet.
Redshift
Tutti i clienti Redshift sono stati mitigati per questo CVE.
Gateway di archiviazione
Storage Gateway ha fornito versioni aggiornate per tutti i gateway supportati. Questo aggiornamento è immediatamente disponibile per un aggiornamento manuale tramite la console e l'API AWS. Questo aggiornamento verrà applicato automaticamente in base alla finestra di manutenzione. Ti consigliamo di eseguire subito un aggiornamento manuale per velocizzare l'applicazione delle patch al gateway.
AWS Cloud9
Gli ambienti AWS Cloud9 EC2 installano automaticamente gli aggiornamenti di Amazon Linux e Ubuntu, ma un kernel aggiornato ha effetto solo dopo il riavvio dell'ambiente. Dopo l’installazione dell’aggiornamento, i clienti devono riavviare l’istanza EC2 di ciascun ambiente o arrestare l’ambiente e riavviarlo. Canonical non ha ancora rilasciato un kernel corretto per Ubuntu. I clienti che utilizzano ambienti Ubuntu devono riavviarli dopo l’installazione del kernel corretto. I clienti che utilizzano ambienti SSH AWS Cloud9 sono responsabili dell’aggiornamento del kernel sui propri server.
Amazon GameLift
Amazon GameLift Servers ha rilasciato AMI Amazon Linux 2 e Amazon Linux 2023 aggiornate che risolvono questo problema in tutte le Regioni. I parchi di container creati dopo il 2 novembre 2026, 13:06 PST (2 novembre 2026, 21:06 UTC) e i parchi EC2 gestiti creati dopo il 2 novembre 2026, 17:55 PST (3 novembre 2026, 01:55 UTC), utilizzano le AMI aggiornate che hanno mitigato questo CVE. I clienti che utilizzano parchi di container o parchi EC2 gestiti creati prima di tali orari dovrebbero creare un nuovo parco, trasferire su di esso il traffico delle sessioni di gioco, ad esempio aggiornando le destinazioni o gli alias delle code di sessioni di gioco, e successivamente eliminare il parco precedente. I parchi esistenti continuano a utilizzare l’AMI con cui sono stati creati e non possono essere aggiornati per mitigare preventivamente questo CVE per le istanze appena avviate: ricreare il parco è l’unico meccanismo per mitigare completamente questo rischio. I parchi che eseguono Windows non sono interessati da questo problema. I clienti che utilizzano i parchi Anywhere gestiscono il proprio sistema operativo e devono aggiornare il kernel e riavviare, come descritto sopra per Amazon EC2.
Amazon GameLift Streams
Amazon GameLift Streams offre ambienti di runtime basati su Ubuntu Linux come opzione ai clienti per eseguire le proprie applicazioni. Gli aggiornamenti in sospeso di Canonical verranno rilasciati ai clienti non appena saranno disponibili. Al momento non è richiesta alcuna azione.
Amazon WorkSpaces
I pacchetti Windows di Amazon WorkSpaces non sono interessati da questo problema. I Linux WorkSpaces utilizzano i kernel Linux interessati e devono essere aggiornati non appena i kernel corretti diventano disponibili presso il fornitore del sistema operativo applicabile.
Nella configurazione predefinita di WorkSpaces, i Linux WorkSpaces non accettano connessioni in entrata dall’esterno del WorkSpace e il gruppo di sicurezza predefinito di WorkSpaces non consente l’accesso in entrata. L’impatto sui clienti aumenta se i clienti hanno aperto porte in entrata verso Linux WorkSpaces, come SSH, o eseguono i propri servizi TCP, in particolare i servizi abilitati per MPTCP.
Le istanze Amazon WorkSpaces Personal con Amazon Linux 2 possono ricevere il kernel Amazon Linux corretto tramite i meccanismi di manutenzione di WorkSpaces esistenti. I clienti devono assicurarsi che i Linux WorkSpaces possano accedere ai repository di aggiornamento del sistema operativo e riavviare i WorkSpaces dopo aver installato i kernel corretti in modo che il kernel aggiornato sia attivo.
I parchi Amazon WorkSpaces Applications e i generatori di immagini con Amazon Linux 2 possono ricevere il kernel Amazon Linux corretto creando un’immagine aggiornata tramite l’interfaccia a riga di comando o l’SDK di AWS oppure avviando e aggiornando un generatore di immagini o un’immagine esistente e quindi creandone una nuova. In entrambi i casi, i clienti dovrebbero concludere aggiornando i propri parchi per utilizzare la nuova immagine.
Per le distribuzioni Linux di terze parti come Ubuntu, Red Hat Enterprise Linux e Rocky Linux, la disponibilità di kernel corretti dipende dal rispettivo fornitore del sistema operativo. I clienti devono monitorare gli avvisi del proprio fornitore e applicare gli aggiornamenti quando disponibili. Nelle istanze di Amazon WorkSpaces Personal che eseguono Ubuntu, l’installazione di un kernel corretto potrebbe non proteggere il WorkSpace in esecuzione fino al riavvio del WorkSpace, a meno che il fornitore non fornisca una livepatch applicabile installata e attiva.
Le AutoStop WorkSpaces che vengono arrestate non sono in esecuzione e non possono subire alcun effetto in caso di arresto; dovranno installare gli aggiornamenti e riavviarle al successivo avvio o durante la finestra di manutenzione. I clienti che hanno disattivato la modalità di manutenzione o limitano l’accesso al repository devono verificare che gli aggiornamenti vengano applicati.
Le istanze Linux WorkSpaces Personal di nuova creazione installano gli aggiornamenti disponibili del sistema operativo durante il provisioning. Una volta che i kernel corretti sono disponibili nel relativo repository del sistema operativo, i Linux WorkSpaces appena creati dovrebbero avviarsi con il kernel corretto disponibile al termine del provisioning.
AWS Database Migration Service (AWS DMS)
Le istanze di replica AWS DMS, incluse quelle che eseguono repliche di AWS DMS Serverless, non accettano connessioni in entrata provenienti dalle reti dei clienti o da Internet; di conseguenza, non esiste alcun percorso che permetta a soggetti esterni di inviare a tali istanze il traffico necessario per provocare questo problema.
Come misura di difesa in profondità, AWS DMS applicherà il kernel con patch a tutte le istanze di replica e alle repliche AWS DMS Serverless. L’aggiornamento sarà disponibile in tutte le regioni AWS entro il 2 novembre 2026. AWS DMS lo applicherà durante una finestra di manutenzione settimanale, con un riavvio. Durante il riavvio, le attività in esecuzione si interrompono e riprendono e le tabelle ancora in caricamento completo vengono riavviate. Per scegliere quando ciò deve avvenire, modificare la finestra di manutenzione dell’istanza di replica.
Per ottenere l'aggiornamento prima, controlla se `aws dms describe-pending-maintenance-actions` elenca un'azione os-patch per la tua istanza di replica. In tal caso, applicarla immediatamente. Questo riavvia subito l’istanza:
| aws dms apply-pending-maintenance action --replication-instance-arn --apply-action os-patch --opt-in-type immediate |
Amazon MQ
Amazon MQ ha rilasciato un’immagine host aggiornata con il kernel con patch per Amazon MQ per RabbitMQ e Amazon MQ per ActiveMQ. I broker creati dopo il 2 novembre 2026, 12:16 UTC, utilizzano il kernel con patch. I broker esistenti vengono aggiornati automaticamente durante la successiva finestra di manutenzione programmata e non è richiesta alcuna azione da parte del cliente. Per applicare l’aggiornamento prima, modificare la finestra di manutenzione del broker impostandola su un orario precedente. Il riavvio di un broker non comporta l’applicazione di questo aggiornamento. Per ulteriori informazioni, consultare Pianificazione della finestra di manutenzione per un broker Amazon MQ.
AWS CodeBuild
Gli host di build di CodeBuild Linux eseguono le versioni del kernel interessate. Il kernel appartiene all'host di compilazione, non all'immagine di compilazione, quindi tutte le build di Linux sono interessate indipendentemente dall'immagine utilizzata.
- Flotte su richiesta: Le AMI host di build x86_64 aggiornate sono distribuite in tutte le regioni commerciali a partire dal 2026-11-05. Eseguono il kernel 4.14.355-287.758 su Amazon Linux 2 e 6.1.189-236.400 su Amazon Linux 2023. Le AMI ARM (aarch64) aggiornate sono distribuite in tutte le regioni commerciali a partire dal 2026-11-06. Non è necessaria alcuna azione da parte del cliente.
- Flotte con capacità riservata: Le AMI aggiornate per le flotte x86_64 e ARM, con calcolo container e calcolo EC2, sono implementate in tutte le regioni commerciali a partire dal 09-11-2020. Se la tua flotta utilizza un AMI personalizzata, ricostruiscilo con il kernel patchato e aggiorna la flotta per utilizzare la nuova AMI.
Non è necessario modificare le immagini di build o le specifiche di build. Per verificare su quale kernel è stata eseguita una build, aggiungi uname -r alla tua buildspec.
AWS Deep Learning AMI (DLAMI)
I DLAM di Amazon Linux 2023 sono: Sono stati rilasciati DLAMI aggiornati con il kernel patchato (kernel6.12 6.12.113-138.209). Per i dettagli, consulta la Note sulla versione DLAMI (ad esempio, AMI GPU AWS Deep Learning Base (Amazon Linux 2023)). Avvia nuove istanze dall'ultima versione di Amazon Linux 2023 DLAMI. Per aggiornare le istanze esistenti, aggiorna il kernel e riavvia:
| sudo dnf update kernel6.12 --releasever=latest && sudo reboot |
Ubuntu 22.04 e 26.04 DLAMis: I DLAMI aggiornati con i kernel fissi di Canonical sono in fase di implementazione e saranno presto disponibili in tutte le regioni. Avvia nuove istanze dall'ultima versione di Ubuntu 22.04 o 26.04 DLAMI.
I DLAM di Ubuntu 24.04 sono: I DLAMI aggiornati non sono ancora disponibili. Rilasceremo i DLAMI aggiornati di Ubuntu 24.04 dopo che il kernel fisso di Canonical sarà disponibile e aggiorneremo questo bollettino quando verranno rilasciati.
Servizio di calcolo parallelo AWS (AWS PCS)?
AWS PCS ha corretto i controller Slurm di tutti i cluster PCS a partire dal 1° novembre 2026. Non è richiesta alcuna azione da parte del cliente per i controller.
I clienti sono responsabili dell'aggiornamento del kernel sulle istanze dei propri gruppi di nodi di calcolo, inclusi i nodi di accesso. Il 29 ottobre 2026 AWS PCS ha rilasciato delle AMI PCS di esempio aggiornate per Amazon Linux 2023 (x86_64 e arm64) che includono il kernel patchato. Queste AMI sono denominate nel formato aws-pcs-sample_ami-al2023-arm64- e aws-pcs-sample_ami-al2023-x86_64-. Vedere Amazon Machine Images (AMI) per AWS PCS per ulteriori informazioni sulle AMI per PCS.
I clienti che utilizzano le AMI di esempio PCS devono aggiornare i propri gruppi di nodi di calcolo per utilizzare l'AMI di esempio più recente. I clienti che utilizzano le proprie AMI devono ricostruirle con il kernel patchato oppure aggiornare il kernel sulle istanze in esecuzione e riavviarlo. Per riavviare i nodi di calcolo senza perdere la capacità EC2, usa il comando scontrol reboot di Slurm come descritto in Riavvia un nodo di calcolo utilizzando Slurm in AWS PCS.
Le AMI Deep Learning (DLAMI) pronte per PC sono basate su Ubuntu 24.04 e Canonical non ha ancora rilasciato un kernel fisso per Ubuntu. AWS PCS rilascerà DLAMI aggiornati pronti per PC quando sarà disponibile un DLAMI con patch. I clienti che utilizzano AMI basate su Ubuntu devono applicare i passaggi provvisori indicati di seguito fino al rilascio di un kernel con patch per Ubuntu.
Amazon FSx
Stiamo implementando soluzioni di mitigazione in tutto il mondo per risolvere questo problema sui file system Amazon FSx interessati. La soluzione a lungo termine è una patch che è in fase di implementazione e che presto raggiungerà tutte le regioni AWS. Una volta che la patch è disponibile in una regione, i nuovi file system lanciati la includono e i file system esistenti vengono patchati automaticamente durante la successiva finestra di manutenzione settimanale. Non è necessaria alcuna azione da parte del cliente.
Fase temporanea per i clienti che non possono effettuare l’aggiornamento immediatamente
Disabilita MPTCP impostando il parametro del kernel `net.mptcp.enabled=0` o imposta `GODEBUG=MultiPathTCP=0` per le applicazioni create con Go 1.24 o versioni successive. Questo passaggio riduce le condizioni per l’esecuzione del codice su un host, ma non risolve il problema. L’aggiornamento del kernel e il riavvio risolvono il problema.
I clienti possono disabilitare le opzioni IP per mitigare questo problema con una regola delle tabelle IP. Di seguito viene fornito un esempio:
| iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP |
Questa regola non persiste durante i riavvii, a meno che non venga salvata con gli strumenti della tua distribuzione. Amazon Linux 2023 non include iptables per impostazione predefinita.
Firewall di rete AWS
I clienti di Firewall di rete AWS possono mitigare il problema aggiungendo la seguente regola stateful, che elimina i pacchetti IPv4 contenenti opzioni IP. Utilizzare un SID che non sia già utilizzato nei loro gruppi di regole:
| drop ip any any -> any any (msg:"CVE-2026-98432: drop IPv4 packets carrying IP options (IHL > 5)"; ipv4.hdr; bsize:>20; sid:1000001; rev:3;) |
La policy del firewall deve utilizzare un ordine di regole rigoroso. Assegnare a questo gruppo di regole un numero di priorità inferiore rispetto ai gruppi di regole di autorizzazione. Il traffico lasciato passare dalle regole stateless salta questa regola.
Se la policy utilizza l’ordine predefinito, creare una nuova policy in ordine rigoroso e ricreare i gruppi di regole stateful in ordine rigoroso. Quindi passare il firewall alla nuova policy. Questa operazione modifica il modo in cui tutte le regole vengono valutate e può interrompere le connessioni esistenti, quindi è consigliabile eseguire prima dei test ed effettuare il monitoraggio dopo la modifica.
Come ulteriore misura di difesa in profondità, AWS sta applicando protezioni a livello di rete relative a questo problema. Queste protezioni non sostituiscono le mitigazioni consigliate per questo problema e consigliamo ai clienti di continuare ad applicare le linee guida contenute in questo bollettino.
Riferimenti:
Per favore invia un'email aws-security@amazon.com per qualsiasi domanda o dubbio sulla sicurezza.