Utilizza queste istruzioni per risolvere i problemi relativi ai criteri di sicurezza di Google Cloud Armor.
Problemi generici
Debug dei criteri di sicurezza
Se hai bisogno di ulteriori informazioni su quale evento specifico attiva regole preconfigurate, consulta Utilizzo del logging delle richieste e poi abilita il logging dettagliato. Cloud Logging registra un livello di dettaglio superiore nei log, che puoi utilizzare per analizzare ed eseguire il debug di criteri e regole.
Il traffico è consentito nonostante una regola di negazione configurata nel criterio di sicurezza di Google Cloud Armor
Per risolvere il problema:
Assicurati che il criterio di sicurezza di Google Cloud Armor sia collegato a un servizio di backend di destinazione. Ad esempio, il comando seguente descrive tutti i dati associati al servizio di backend
BACKEND. I risultati restituiti devono includere il nome del criterio di sicurezza di Google Cloud Armor associato a questo servizio di backend.gcloud compute backend-services describe BACKEND
Esamina i log HTTP(S) per determinare quali criteri e regole sono stati abbinati per il tuo traffico insieme all'azione associata. Per visualizzare i log, utilizza Cloud Logging.
Di seguito è riportato un log di esempio di una richiesta consentita con i campi interessanti evidenziati. Verifica i seguenti campi e assicurati che corrispondano alla regola configurata per negare il traffico:
configuredActiondeve corrispondere all'azione configurata nella regola.namedeve corrispondere al nome del criterio di sicurezza di Google Cloud Armor associato a questo servizio di backend.outcomedeve corrispondere aconfiguredAction.prioritydeve corrispondere al numero di priorità della regola.
httpRequest: remoteIp: 104.133.0.95 requestMethod: GET requestSize: '801' requestUrl: http://74.125.67.38/ responseSize: '246' serverIp: 10.132.0.4 status: 200 userAgent: curl/7.35.0 insertId: ajvis5ev4i60 internalId: projectNumber: '895280006100' jsonPayload: '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry enforcedSecurityPolicy: configuredAction: ACCEPT name: mydev-policy-log-test1 outcome: ACCEPT priority: 2147483647 statusDetails: response_sent_by_backend logName: projects/mydev-staging/logs/requests resource: labels: backend_service_name: BACKEND_SERVICE_NAME forwarding_rule_name: FORWARDING_RULE_NAME project_id: PROJECT_ID target_proxy_name: TARGET_HTTP_PROXY_NAME url_map_name: URL_MAP_NAME zone: global type: http_load_balancer severity: INFO timestamp: '2017-04-18T18:57:05.845960288Z'Esamina la gerarchia delle regole per assicurarti che venga soddisfatta la regola corretta. È possibile che una regola di priorità più alta con un'azione di autorizzazione corrisponda al tuo traffico. Utilizza il comando
describesusecurity-policiesin Google Cloud CLI per visualizzare i contenuti del criterio di sicurezza di Google Cloud Armor.Ad esempio, l'esempio seguente mostra come una regola di autorizzazione con priorità più alta (con priorità 100) corrisponda al traffico proveniente dall'indirizzo IP 1.2.3.4, impedendo alla regola di negazione con priorità inferiore (con priorità 200) di attivare e bloccare il traffico.
gcloud compute security-policies describe POLICY_NAME
Output:
creationTimestamp: '2017-04-18T14:47:58.045-07:00 description: '' fingerprint: Yu5spBjdoC0= id: '2560355463394441057' kind: compute#securityPolicy name: POLICY_NAME rules: -action: allow description: allow high priority rule kind: compute#securityPolicyRule match: srcIpRanges: -'1.2.3.4/32' preview: false priority: 100 -action: deny description: deny lower priority rule kind: compute#securityPolicyRule match: srcIpRanges: -'1.2.3.0/24 preview: false priority: 200 -action: deny description: default rule kind: compute#securityPolicyRule match: srcIpRanges: -'*' preview: false priority: 2147483647 selfLink: http://www.googleapis.com/compute/v1/projects/bigclustertestdev0-devconsole/global/securityPolicies/sp
La regola preconfigurata restituisce falsi positivi
Il rilevamento XSS e SQLi si basa sulla corrispondenza della firma statica sulle intestazioni delle richieste HTTP e su altri parametri L7. Questi pattern di espressioni regolari sono soggetti a falsi positivi. Puoi utilizzare la regola preconfigurata per il rilevamento XSS e SQLi in modalità di anteprima e quindi verificare la presenza di falsi positivi nel log.
Se trovi un falso positivo, puoi confrontare il contenuto del traffico con le regole CRS di ModSecurity.
Se la regola non è valida o non è pertinente, disattivala utilizzando l'espressione evaluatePreconfiguredExpr e specifica l'ID della regola nell'argomento exclude ID list.
Dopo aver esaminato i log e rimosso tutti i falsi positivi, disabilita la modalità di anteprima.
Per aggiungere una regola preconfigurata in modalità di anteprima:
Crea un criterio di sicurezza con l'espressione preconfigurata impostata in modalità di anteprima:
gcloud compute security-policies rules create 1000 --security-policy POLICY_NAME --expression "evaluatePreconfiguredExpr('xss-stable')" --action deny-403 --previewEsamina i log HTTP(S) per i campi di richiesta HTTP come
urlecookie. Ad esempio,requestUrlfa un confronto positivo con l'ID regola CRS di ModSecurity 941180:httpRequest: remoteIp: 104.133.0.95 requestMethod: GET requestSize: '801' requestUrl: http://74.125.67.38/foo?document.cookie=1010" responseSize: '246' serverIp: 10.132.0.4 status: 200 userAgent: curl/7.35.0 insertId: ajvis5ev4i60 internalId: projectNumber: '895280006100' jsonPayload: '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry enforcedSecurityPolicy: configuredAction: ACCEPT name: POLICY_NAME outcome: ACCEPT priority: 2147483647 preconfiguredExprIds: [ 'owasp-crs-v030001-id941180-xss' ] statusDetails: response_sent_by_backend logName: projects/mydev-staging/logs/requests resource: labels: backend_service_name: BACKEND_SERVICE forwarding_rule_name: mydev-forwarding-rule project_id: mydev-staging target_proxy_name: mydev-target-http-proxy url_map_name: mydev-url-map zone: global type: http_load_balancer severity: INFO timestamp: '2017-04-18T18:57:05.845960288Z'Escludi l'ID regola CRS ModSecurity 941180 aggiornando la regola nel criterio di sicurezza di Google Cloud Armor:
gcloud compute security-policies rules update 1000 \ --security-policy POLICY_NAME \ --expression "evaluatePreconfiguredExpr('xss-stable', ['owasp-crs-v030001-id941180-xss'])" \ --action deny-403 \ --previewEsamina di nuovo i log e, quindi, disabilita la modalità di anteprima per implementare la regola.
I client con firme negate non vengono bloccati o rifiutati
Se utilizzi Google Cloud Armor con Cloud CDN, i criteri di sicurezza vengono applicati solo alle richieste di contenuti dinamici, ai fallimenti della cache o ad altre richieste destinate al server di origine CDN. I successi della cache vengono pubblicati anche se il criterio di sicurezza downstream di Google Cloud Armor impedirebbe alla richiesta di raggiungere il server di origine CDN.
Riduci il rischio nel corpo POST che supera gli 8 kB quando utilizzi le regole WAF preconfigurate
Quando una regola WAF preconfigurata viene valutata in un criterio di sicurezza di Google Cloud Armor, vengono ispezionati fino a 8 kB del corpo del POST per individuare corrispondenze delle firme in base alle regole WAF. Questo approccio ti offre ispezione e protezione di livello 7 a bassa latenza, mantenendo al contempo la disponibilità per altri clienti Google.
Puoi ridurre il rischio derivante da richieste POST di dimensioni maggiori creando una regola nei criteri di sicurezza per assicurarti che nessun contenuto non ispezionato raggiunga i tuoi backend. Crea una regola per negare il traffico che supera gli 8 kB (8192 byte) nelle dimensioni del corpo del POST. Il seguente esempio di codice mostra come creare questa regola:
gcloud compute security-policies rules create 10 \
--security-policy my-policy \
--expression "int(request.headers['content-length']) > 8192" \
--action deny-403 \
--description "Block requests great than 8KB"
Problemi con gli elenchi di indirizzi IP denominati
Questa sezione fornisce informazioni per la risoluzione dei problemi relativi agli elenchi di indirizzi IP denominati.
Indirizzi IP all'interno di un elenco di indirizzi IP denominato
Gli indirizzi IP negli elenchi corrispondono sempre agli indirizzi IP nei siti web dei provider elencati nella guida agli elenchi di indirizzi IP denominati di Google Cloud Armor. Per qualsiasi domanda sugli elenchi, contatta il team dell'assistenza di Cloud.
Gli indirizzi IP all'interno di un elenco di indirizzi IP denominato non sono aggiornati in Google Cloud Armor
Google Cloud Armor sincronizza ogni giorno i suoi elenchi con i provider di elenchi di indirizzi IP. È possibile che i dati di un provider siano inattivi di alcune ore o di un giorno. Tuttavia, se ritieni che i dati inattivi siano più in ritardo del previsto, ad esempio più di una settimana, contatta il team di assistenza di Cloud.
Difficoltà a creare un criterio di sicurezza che faccia riferimento a un elenco di indirizzi IP denominato
Puoi provare a creare un criterio di sicurezza che faccia riferimento a un elenco di indirizzi IP denominato, utilizzando un comando come questo:
gcloud compute security-policies rules create 750 \
--security-policy my \
--expression "evaluatePreconfiguredExpr('sourceiplist-example')" \
--action "allow"
Se il comando non riesce, l'errore che vedi è simile al seguente:
ERROR: (gcloud.compute.security-policies.rules.create) Could not fetch resource:
- Invalid value for field 'resource.match.expr': '{ "expression": "evaluatePreconfiguredExpr(\u0027sourceiplist-example\u0027)"}'.
Error parsing Google Cloud Armor rule matcher expression: sourceiplist-example
is not a valid preconfigured expression set.
Assicurati che il provider specifico sia supportato e che il nome dell'elenco di indirizzi IP sia fornito correttamente. Puoi verificarlo utilizzando il seguente comando gcloud per elencare gli attuali set di espressioni preconfigurati:
gcloud compute security-policies list-preconfigured-expression-sets
Il traffico è bloccato nonostante una regola preconfigurata per una lista consentita di indirizzi IP specificati
Potresti scoprire che il traffico è bloccato da un indirizzo IP che si trova in un elenco di indirizzi IP denominato:
Assicurati che il traffico provenga da un indirizzo IP che è incluso in una lista consentita di indirizzi IP indicati.
Controlla se esistono altre regole di sicurezza con una priorità più alta che possono bloccare il traffico. Se il problema persiste, contatta il team dell'assistenza di Cloud.
Assicurati che il criterio di sicurezza sia associato al servizio di backend corretto:
gcloud compute backend-services describe BACKEND_SERVICE
Controlla le regole presenti nel criterio di sicurezza. Ad esempio:
gcloud compute security-policies describe POLICY_NAME
Il comando restituisce informazioni simili alle seguenti:
--- … name: POLICY_NAME rules: -action: allow description: allow fastly ip addresses kind: compute#securityPolicyRule match: expr: expression: evaluatePreconfiguredExpr('sourceiplist-fastly') preview: false priority: 100 -action: deny(403) description: Default rule, higher priority overrides it kind: compute#securityPolicyRule match: config: srcIpRanges: -'*' versionedExpr: SRC_IPS_V1 preview: false priority: 2147483647 -action: deny(404) description: deny altostrat referer kind: compute#securityPolicyRule match: expr: expression: request.headers['Referer'].contains('altostrat') preview: false priority: 50 …Il criterio di sicurezza precedente contiene tre regole: una regola di negazione predefinita, una regola di autorizzazione per gli indirizzi IP di Fastly e una regola di negazione per un referrer che contiene
altostrat. Sono elencate anche le rispettive priorità.Esamina i log per determinare quale regola corrisponde al tuo traffico e l'azione associata. Per informazioni sul logging, consulta Utilizzo di Esplora log.
Di seguito è riportato un esempio di log:
httpRequest: { referer: "http://www.altostrat.com/" remoteIp: "23.230.32.10" requestMethod: "HEAD" requestSize: "79" requestUrl: "http://www.example.com/" responseSize: "258" status: 404 userAgent: "Mozilla/5.0" } … jsonPayload: { @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry" enforcedSecurityPolicy: { configuredAction: "DENY" name: "POLICY_NAME" outcome: "DENY" priority: 50 } statusDetails: "denied_by_security_policy" } …Nel log precedente, la richiesta proviene da
23.230.32.10, coperto dall'elenco di indirizzi IP pubblici di Fastly. Tuttavia, la richiesta corrisponde a una regola di negazione con priorità più elevata 50. Confrontando questa impostazione con i contenuti del criterio di sicurezza, la regola corrisponde alla regola di negazione per un referrer che contienealtostrat. Poiché la richiesta ha un referrerhttp://www.altostrat.com/, l'applicazione della regola di sicurezza funziona correttamente.
Problemi con i risultati di Security Command Center
Questa sezione contiene informazioni sui problemi relativi ai risultati di Security Command Center.
La scheda Google Cloud Armor non viene visualizzata in Security Command Center
Abilita i risultati di Google Cloud Armor nell'interfaccia di Security Command Center.
I risultati di Google Cloud Armor non vengono visualizzati in Security Command Center
Se i risultati di Google Cloud Armor non vengono visualizzati in Security Command Center, il traffico verso i servizi di backend potrebbe non soddisfare i criteri per generare un risultato.
Per domande sul volume di traffico verso i tuoi backend, controlla le statistiche delle richieste nelle dashboard di Cloud Monitoring in Criteri di sicurezza della rete.
I risultati sono troppo rumorosi
Per ricevere aiuto in merito a questo problema, contatta il team dell'assistenza Cloud.
Problemi con Google Cloud Armor Adaptive Protection
Segui queste istruzioni per risolvere i problemi relativi a Adaptive Protection.
Adaptive Protection è abilitato per un criterio di sicurezza, ma non sono presenti log in Cloud Logging
I log di Adaptive Protection vengono generati separatamente dai log delle richieste di Google Cloud Armor e vengono visualizzati in una risorsa diversa in Cloud Logging. I log e gli eventi di Adaptive Protection si trovano nella risorsa Criterio di sicurezza di rete in Cloud Logging. Esiste un periodo di addestramento di almeno un'ora dopo l'abilitazione di Adaptive Protection in un criterio di sicurezza prima che Adaptive Protection inizi a generare avvisi per sospetti attacchi. Durante il periodo di addestramento, Adaptive Protection apprende dal traffico delle richieste in entrata e sviluppa basi distinte per ciascun servizio di backend protetto da tale criterio di sicurezza. Adaptive Protection è in grado di identificare in un secondo momento le attività sospette.
Se abiliti Adaptive Protection per un criterio di sicurezza e non osservi alcun avviso dopo un periodo di addestramento di un'ora, significa che non è presente alcuna attività che possa essere identificata come targeting potenzialmente dannoso per i servizi di backend associati al criterio di sicurezza.
Se il potenziale attacco o il traffico anomalo persiste per periodi di tempo più lunghi, superando diverse ore, Adaptive Protection inizia a considerare tale comportamento come comportamento di riferimento e non continua ad avvisare su pattern di traffico simili. Una volta che il potenziale attacco cessa e i modelli di traffico tornano alla base di riferimento originale, o perché l'attacco si è concluso o l'hai bloccato con le regole appropriate di Google Cloud Armor, Adaptive Protection avvisa su comportamenti futuri del traffico considerati partenze dalla base di riferimento.
Adaptive Protection analizza il traffico che altrimenti sarebbe consentito tramite un criterio di sicurezza di Google Cloud Armor. Se imposti la regola predefinita per negare l'accesso con un elenco di traffico consentito con restrizioni, Adaptive Protection rileva solo le attività dannose sul traffico che supera la valutazione nel rispetto della lista consentita.
Troppi avvisi o troppi log in Cloud Logging da Adaptive Protection
Un avviso di Adaptive Protection fornisce un punteggio di affidabilità, che indica con che intensità i modelli di Adaptive Protection identificano l'attività rilevata come anomalia e potenzialmente un attacco. Puoi filtrare in base alla voce specifica del log tramite Cloud Logging per visualizzare (o inoltrare direttamente al downstream) solo gli avvisi con un punteggio di affidabilità superiore a una determinata soglia.
Adaptive Protection fornisce un meccanismo per segnalare gli avvisi come falsi positivi, come descritto nella sezione Monitoraggio, feedback e segnalazione di errori relativi agli eventi. Tieni presente che le segnalazioni di falsi positivi potrebbero non comportare modifiche immediate agli avvisi di Adaptive Protection. Nel tempo, i modelli di Adaptive Protection apprendono che questi modelli di traffico sono normali e accettabili e Adaptive Protection smette di generare avvisi per questi pattern.
Se gli avvisi di Adaptive Protection sono troppo frequenti su un sottoinsieme di servizi di backend in un criterio di sicurezza, potrebbe suggerire che il traffico normale di questi servizi di backend abbia fluttuazioni significative che vengono costantemente identificate da Adaptive Protection come comportamenti anomali. Puoi creare un criterio di sicurezza separato senza Adaptive Protection abilitato e associare questi servizi di backend al nuovo criterio di sicurezza.
Un determinato incidente segnalato da Adaptive Protection è considerato un falso positivo o non è pertinente.
Adaptive Protection fornisce un meccanismo per la segnalazione di falsi positivi. Segui la procedura descritta nella sezione Errori relativi a eventi di monitoraggio, feedback e segnalazione. Tieni presente che le segnalazioni di falsi positivi potrebbero non comportare modifiche immediate agli avvisi di Adaptive Protection. Nel tempo, i modelli di Adaptive Protection apprendono che questi modelli di traffico sono normali e accettabili e Adaptive Protection smette di generare avvisi per questi pattern.
Come faccio a sapere che i miei criteri di sicurezza perimetrale vengono applicati?
Puoi verificare le azioni intraprese sui criteri di sicurezza perimetrale controllando le dashboard di monitoraggio, le metriche di monitoraggio o il logging per richiesta.
Dashboard di Monitoring
Cloud Monitoring è disponibile nella pagina Criteri di sicurezza di rete in Monitoring. Puoi utilizzare la suddivisione per criterio di sicurezza nella pagina per misurare il numero di richieste consentite e rifiutate dal criterio di sicurezza perimetrale configurato. Puoi anche esaminare la suddivisione per servizio di backend per eseguire il debug di un servizio di backend specifico. Per maggiori dettagli sulla dashboard di Cloud Monitoring, consulta Monitoraggio dei criteri di sicurezza di Google Cloud Armor.
Monitoraggio delle metriche
Le metriche non elaborate che misurano le richieste consentite e rifiutate sono disponibili per i criteri di sicurezza perimetrale. Per maggiori informazioni, consulta Monitorare le metriche per i criteri di sicurezza.
Logging per richiesta
La decisione relativa al criterio di sicurezza perimetrale viene registrata nei log delle richieste di bilanciamento del carico in enforcedEdgeSecurityPolicy. È separato da
enforcedSecurityPolicy, che acquisisce la decisione del criterio di sicurezza del backend.
Gestione di bot
Questa sezione contiene informazioni sulla risoluzione dei problemi relativi alla gestione dei bot.
Gli utenti non sono esenti come previsto
Potresti aver configurato le regole dei criteri di sicurezza con l'azione di reindirizzamento per la valutazione reCAPTCHA Enterprise e scoprire che alcuni utenti che ritieni legittimi non sono stati esentati come previsto. Per risolvere il problema, procedi nel seguente modo.
Innanzitutto, controlla nei log delle singole richieste se esiste una regola del criterio di sicurezza con una priorità più alta che corrisponde al traffico, in cui l'azione è diversa. In particolare, cerca i campi configured_action e outcome.
Tieni presente che affinché un utente sia esentato, vengono coinvolte almeno due richieste. La richiesta iniziale viene fornita senza un cookie di esenzione e le richieste successive vengono fornite con un cookie di esenzione se l'utente supera la valutazione di reCAPTCHA Enterprise. Pertanto, sono previste almeno due voci di log.
- Se vedi
GOOGLE_RECAPTCHAcome azione configurata eREDIRECTcome risultato, la richiesta è stata reindirizzata per la valutazione di reCAPTCHA Enterprise. - Se vedi
GOOGLE_RECAPTCHAcome azione configurata eACCEPTcome risultato, la richiesta è stata esente dal reindirizzamento per la valutazione reCAPTCHA Enterprise. - Se vedi valori diversi nei campi precedenti, è stata trovata una corrispondenza con una regola con un'azione diversa. In questo caso, si prevede che l'utente non venga reindirizzato o esentato.
In secondo luogo, gli utenti devono rispettare diversi requisiti per essere esonerati dal reindirizzamento per la valutazione di reCAPTCHA Enterprise.
- L'utente deve utilizzare un browser.
- Il browser deve abilitare JavaScript per consentire il caricamento corretto della pagina di reindirizzamento con il JavaScript di reCAPTCHA Enterprise incorporato.
- Il browser deve abilitare i cookie per consentire l'impostazione e il collegamento automatico del cookie di esenzione.
- L'utente deve superare la valutazione reCAPTCHA Enterprise; ad esempio, deve risolvere eventuali verifiche popup.
Gli utenti che non possono soddisfare i requisiti riportati sopra non riceveranno l'esenzione, anche se corrisponde a una regola con l'azione di reindirizzamento per la valutazione reCAPTCHA Enterprise.
In terzo luogo, la valutazione di reCAPTCHA Enterprise viene eseguita solo quando viene visualizzata la pagina di reindirizzamento che incorpora il codice JavaScript di reCAPTCHA Enterprise. Per questo motivo, il reindirizzamento per la valutazione di reCAPTCHA Enterprise è applicabile solo per le richieste che si aspettano una risposta che porti al rendering completo della pagina. Altre richieste, come il caricamento di asset all'interno di una pagina o le richieste provenienti da uno script incorporato che non si aspettano che la risposta venga visualizzata, non sono previste per ricevere la valutazione di reCAPTCHA Enterprise. Di conseguenza, ti consigliamo di applicare questa azione con una condizione di corrispondenza per i percorsi degli URL che soddisfano questa condizione.
Ad esempio, supponi di avere una pagina web che contiene elementi incorporati come immagini, link ad altre pagine web e script. Non vuoi applicare l'azione di reindirizzamento per la valutazione di reCAPTCHA Enterprise per i percorsi URL che ospitano immagini o che dovrebbero essere accessibili da script in cui non è prevista una visualizzazione a pagina intera. Puoi invece applicare l'azione di reindirizzamento per la valutazione reCAPTCHA Enterprise per i percorsi degli URL che ospitano pagine web, come la pagina web principale o altre pagine web collegate.
Infine, se il rendering della pagina di reindirizzamento viene eseguito correttamente, controlla nello Strumento per sviluppatori fornito dal browser se è impostato un cookie di esenzione e se è allegato nelle richieste successive per lo stesso sito. Per ulteriore assistenza, puoi contattare il team di assistenza Cloud.
Problemi con la limitazione di frequenza
Il traffico non è limitato come previsto
Potresti scoprire che un indirizzo IP client invia livelli elevati di traffico a un'applicazione a una velocità superiore alla soglia impostata, ma il traffico non viene limitato come previsto. Segui questi passaggi per esaminare il problema.
Innanzitutto, conferma se una regola di priorità più alta consente il traffico da quell'indirizzo IP. Esamina i log per verificare se è stata attivata una regola ALLOW per l'indirizzo IP. Potrebbe essere una regola ALLOW separata o in un'altra regola THROTTLE o RATE_BASED_BAN.
Se trovi una regola di priorità più alta, procedi in uno dei seguenti modi:
- Modifica le priorità per garantire che la regola di limitazione della frequenza abbia una priorità più alta, assegnando un valore numerico inferiore.
- Escludi l'indirizzo IP dall'espressione corrispondente nella regola con una priorità maggiore.
Il problema potrebbe anche essere dovuto all'impostazione errata della soglia. In questo caso, le richieste vengono associate in modo preciso, ma viene attivata l'azione conforme. Esamina i log per confermare che sia così, quindi riduci la soglia nella regola.
Infine, l'indirizzo IP potrebbe non corrispondere alla regola di limitazione o di esclusione basata sulla frequenza. Per risolvere il problema, verifica la presenza di un errore nella condizione di corrispondenza, poi modifica la condizione di corrispondenza della regola impostandola sul valore corretto.