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 le regole preconfigurate, leggi Utilizzo della registrazione delle richieste e poi attiva la registrazione dettagliata. Cloud Logging registra un livello di dettaglio più elevato nei log, che puoi utilizzare per analizzare ed eseguire il debug di criteri e regole.
Il traffico è consentito nonostante una regola di negazione configurata nei criteri di sicurezza di Google Cloud Armor
Per risolvere il problema, segui questi passaggi:
Assicurati che i criteri di sicurezza di Google Cloud Armor siano collegati a un servizio di backend di destinazione. Ad esempio, il seguente comando descrive tutti i dati associati al servizio di backend
BACKEND. I risultati restituiti devono includere il nome del criterio di sicurezza 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 al tuo traffico, nonché l'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. Controlla i seguenti campi e assicurati che corrispondano alla regola che hai configurato per negare il traffico:
configuredActiondeve corrispondere all'azione configurata nella regola.namedeve corrispondere al nome dei criteri di sicurezza di Google Cloud Armor collegati 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'Rivedi la gerarchia delle regole per assicurarti che venga abbinata la regola corretta. È possibile che una regola con priorità più elevata con un'azione di autorizzazione corrisponda al tuo traffico. Utilizza il comando
describesusecurity-policiesin Google Cloud CLI per visualizzare i contenuti dei criteri di sicurezza di Google Cloud Armor.Ad esempio, il seguente esempio mostra come una regola di autorizzazione con priorità più elevata (con priorità 100) corrisponde al traffico proveniente dall'indirizzo IP 1.2.3.4, impedendo l'attivazione della regola di negazione con priorità inferiore (con priorità 200) e il blocco del 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 di XSS e SQLi si basa sulla corrispondenza statica delle firme nelle intestazioni delle richieste HTTP e in altri parametri L7. Questi pattern di espressioni regolari sono soggetti a falsi positivi. Puoi utilizzare la regola preconfigurata per il rilevamento di XSS e SQLi in modalità di anteprima e poi controllare il log per eventuali falsi positivi.
Se trovi un falso positivo, puoi confrontare i contenuti del traffico con le
regole OWASP CRS.
Se la regola non è valida o pertinente, disattivala utilizzando l'espressione
evaluatePreconfiguredWaf e specifica l'ID della regola nell'argomento
exclude ID list.
Dopo aver esaminato i log e rimosso tutti i falsi positivi, disattiva la modalità di anteprima.
Per aggiungere una regola preconfigurata in modalità di anteprima:
Crea un criterio di sicurezza con l'insieme di espressioni preconfigurato in modalità di anteprima:
gcloud compute security-policies rules create 1000 --security-policy POLICY_NAME --expression "evaluatePreconfiguredWaf('xss-stable')" --action deny-403 --previewEsamina i log HTTP(S) per i campi della richiesta HTTP, ad esempio
urlecookie. Ad esempio,requestUrlha un confronto positivo con l'ID regola OWASP CRS 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 OWASP CRS 941180 aggiornando la regola nel criterio di sicurezza di Google Cloud Armor:
gcloud compute security-policies rules update 1000 \ --security-policy POLICY_NAME \ --expression "evaluatePreconfiguredWaf('xss-stable', ['owasp-crs-v030001-id941180-xss'])" \ --action deny-403 \ --previewEsamina di nuovo i log, quindi disattiva la modalità di anteprima per implementare la regola.
I client con firme rifiutate 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 gestiti anche se il criterio di sicurezza Google Cloud Armor downstream impedirebbe alla richiesta di raggiungere il server di origine CDN.
Problemi con gli elenchi di indirizzi IP denominati
Questa sezione fornisce informazioni per risolvere i 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. In caso di domande sulle liste, contatta il team di assistenza Google Cloud.
Gli indirizzi IP all'interno di un elenco di indirizzi IP denominati sono obsoleti in Google Cloud Armor
Google Cloud Armor sincronizza i suoi elenchi con i fornitori di elenchi di indirizzi IP ogni giorno. È possibile che i dati non siano aggiornati e che siano in ritardo di qualche ora o di un giorno rispetto a quelli di un provider. Tuttavia, se ritieni che i dati obsoleti siano più vecchi 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 denominati
Potresti provare a creare un criterio di sicurezza che faccia riferimento a un elenco di indirizzi IP denominati, 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 va a buon fine, l'errore visualizzato è 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 fornitore specifico sia supportato e che il nome dell'elenco di indirizzi IP
sia indicato correttamente. Puoi verificarlo utilizzando il seguente comando
gcloud per elencare i set di espressioni preconfigurati attuali:
gcloud compute security-policies list-preconfigured-expression-sets
Il traffico viene bloccato nonostante una regola preconfigurata per una lista consentita di indirizzi IP denominati
Potresti notare che il traffico viene bloccato da un indirizzo IP presente in un elenco di indirizzi IP denominato:
Assicurati che il traffico provenga da un indirizzo IP presente in una lista consentita di indirizzi IP denominati.
Controlla se esistono altre regole di sicurezza con una priorità più alta che possono bloccare il traffico. Se il problema persiste, contatta il team di assistenza Cloud.
Assicurati che il criterio di sicurezza sia collegato 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 a quale regola corrisponde il tuo traffico e l'azione associata. Per informazioni sulla registrazione, vedi Utilizzare 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" } …Dal log precedente, la richiesta proviene da
23.230.32.10, che è coperto dall'elenco degli indirizzi IP pubblici di Fastly. Tuttavia, la richiesta corrisponde a una regola di negazione con una priorità più alta di 50. Se lo confrontiamo con quanto riportato nel criterio di sicurezza, la regola corrisponde alla regola di negazione per un referrer che contienealtostrat. Poiché la richiesta ha un referrer dihttp://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 backend, controlla le statistiche sulle richieste nelle dashboard di Cloud Monitoring nella sezione Norme di sicurezza di rete.
I risultati sono troppo rumorosi
Per ricevere assistenza in merito a questo problema, contatta il team di assistenza Cloud.
Problemi con Google Cloud Armor Adaptive Protection
Segui queste istruzioni per risolvere i problemi relativi ad Adaptive Protection.
Adaptive Protection è abilitato per una policy 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 Policy di sicurezza di rete in Cloud Logging. Dopo l'abilitazione di Adaptive Protection in una policy di sicurezza, è previsto un periodo di addestramento di almeno un'ora prima che Adaptive Protection inizi a generare avvisi per attacchi sospetti. Durante il periodo di addestramento, Adaptive Protection apprende dal traffico di richieste in entrata e sviluppa baseline distinte per ogni servizio di backend protetto da questa policy di sicurezza. Adaptive Protection è quindi in grado di identificare attività sospette.
Se abiliti Adaptive Protection per una policy 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 di uno dei servizi di backend associati a quella policy 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 questo comportamento come comportamento di base e non continua a inviare avvisi su pattern di traffico simili. Una volta che il potenziale attacco si attenua e i pattern di traffico tornano alla base di riferimento originale, perché l'attacco è terminato o perché lo hai bloccato con le regole Google Cloud Armor appropriate, Adaptive Protection avvisa in merito a comportamenti futuri del traffico che vengono considerati deviazioni 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 una lista consentita di traffico limitata, Adaptive Protection rileva solo l'attività dannosa sul traffico che supera la valutazione rispetto alla lista consentita.
Sono presenti troppi avvisi o troppi log in Cloud Logging da Adaptive Protection
Un avviso di Adaptive Protection fornisce un punteggio di affidabilità, che indica con quale certezza i modelli di Adaptive Protection identificano l'attività rilevata come anomala e potenzialmente un attacco. Puoi filtrare la voce specifica del log tramite Cloud Logging per visualizzare (o inoltrare a valle) solo gli avvisi con un punteggio di confidenza superiore a una determinata soglia.
Adaptive Protection fornisce un meccanismo per segnalare gli avvisi come falsi positivi, descritto nella sezione Monitoraggio, feedback e segnalazione di errori relativi agli eventi. Tieni presente che la segnalazione di falsi positivi potrebbe non comportare modifiche immediate agli avvisi di Adaptive Protection. Nel tempo, i modelli di Adaptive Protection imparano che questi pattern di traffico sono normali e accettabili e Adaptive Protection smette di inviare avvisi su questi pattern.
Se gli avvisi di Adaptive Protection sono troppo frequenti su un sottoinsieme di servizi di backend in una policy di sicurezza, potrebbe significare che il traffico normale di questi servizi di backend presenta 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 segnalare gli avvisi di falsi positivi. Segui la procedura descritta nella sezione Monitoraggio, feedback e segnalazione degli errori degli eventi. Tieni presente che la segnalazione di falsi positivi potrebbe non comportare modifiche immediate agli avvisi di Adaptive Protection. Nel tempo, i modelli di Adaptive Protection imparano che questi pattern di traffico sono normali e accettabili e Adaptive Protection smette di inviare avvisi relativi a questi pattern.
Come faccio a sapere che le mie norme di sicurezza perimetrale vengono applicate?
Puoi controllare le azioni intraprese in base ai criteri di sicurezza perimetrale controllando le dashboard di monitoraggio, le metriche di monitoraggio o la registrazione per richiesta.
Dashboard di Monitoring
Cloud Monitoring è disponibile nella pagina Policy di sicurezza di rete in Monitoraggio. 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 informazioni dettagliate sulla dashboard di Cloud Monitoring, vedi 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 Metriche di monitoraggio per le norme 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. Questo è separato da
enforcedSecurityPolicy, che acquisisce la decisione relativa al 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 esentati come previsto
Potresti aver configurato regole dei criteri di sicurezza con l'azione di reindirizzamento per la test reCAPTCHA e scoprire che alcuni utenti che ritieni legittimi non sono stati esentati come previsto. Segui i passaggi riportati di seguito per risolvere il problema.
Innanzitutto, controlla i log per richiesta per verificare 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 per l'esenzione di un utente sono coinvolte almeno due richieste. La
richiesta iniziale non include un cookie di esenzione, mentre le richieste successive
includono un cookie di esenzione se l'utente supera la valutazione
reCAPTCHA. Pertanto, sono previste almeno due voci di log.
- Se visualizzi
GOOGLE_RECAPTCHAcome azione configurata eREDIRECTcome risultato, la richiesta è stata reindirizzata pertest reCAPTCHAA; - Se vedi
GOOGLE_RECAPTCHAcome azione configurata eACCEPTcome risultato, la richiesta è stata esentata dal reindirizzamento per test reCAPTCHA. - Se vedi valori diversi nei campi sopra indicati, è stata trovata una regola con un'azione diversa. In questo caso, è previsto che l'utente non venga reindirizzato o esentato.
In secondo luogo, esistono diversi requisiti da parte dell'utente per essere esonerato dal reindirizzamento per la test reCAPTCHA.
- L'utente deve utilizzare un browser.
- Il browser deve abilitare JavaScript per consentire il corretto caricamento della pagina di reindirizzamento con JavaScript di reCAPTCHA incorporato.
- Il browser deve abilitare i cookie per consentire l'impostazione e l'allegato automatico del cookie di esenzione.
- L'utente deve superare test reCAPTCHA, ad esempio deve risolvere le richieste di verifica popup, se presenti.
Tieni presente che gli utenti che non soddisfano uno dei requisiti sopra indicati non riceveranno l'esenzione, anche se viene trovata una regola con l'azione di reindirizzamento per la test reCAPTCHAHA.
Terzo, il test reCAPTCHA viene eseguito solo quando viene visualizzata la pagina di reindirizzamento che incorpora il codice JavaScript reCAPTCHA. Per questo motivo, il reindirizzamento per test reCAPTCHA è applicabile solo alle richieste che prevedono una risposta che porti al rendering di una pagina completa. Altre richieste, come il caricamento di asset all'interno di una pagina o richieste derivanti da uno script incorporato che non prevede il rendering della risposta, non dovrebbero ottenere test reCAPTCHA. Pertanto, ti consigliamo di applicare questa azione con una condizione di corrispondenza per i percorsi URL che soddisfano questa condizione.
Ad esempio, supponiamo 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 test reCAPTCHA per i percorsi URL che ospitano immagini o a cui devono accedere script in cui non è previsto il rendering di una pagina completa. In alternativa, puoi applicare l'azione di reindirizzamento per la test reCAPTCHA per i percorsi URL che ospitano pagine web, come la pagina web principale o altre pagine web collegate.
Infine, se la pagina di reindirizzamento viene visualizzata correttamente, controlla nello strumento per sviluppatori fornito dal browser per vedere se è impostato un cookie di esenzione e se è allegato alle richieste successive per lo stesso sito. Per ulteriore assistenza, puoi contattare il team di assistenza Cloud.
Problemi con limitazione di frequenza
Il traffico non viene limitato come previsto
Potresti notare che un indirizzo IP client invia livelli elevati di traffico a un'applicazione a una velocità che supera la soglia impostata, ma il traffico non viene limitato come previsto. Segui questi passaggi per esaminare il problema.
Innanzitutto, verifica se una regola con 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 trattarsi di una regola ALLOW a sé stante o di un'altra regola THROTTLE o
RATE_BASED_BAN.
Se trovi una regola con priorità più alta, procedi in uno dei seguenti modi:
- Modifica le priorità per assicurarti che la regola di limitazione della frequenza abbia una priorità più elevata assegnandole un valore numerico inferiore.
- Escludi l'indirizzo IP dall'espressione corrispondente nella regola con una priorità più alta.
Il problema potrebbe anche essere dovuto a una soglia impostata in modo errato. In questo caso, le richieste vengono abbinate con precisione, ma viene attivata l'azione di conformità. Esamina i log per verificare che sia così, poi riduci la soglia nella regola.
Infine, l'indirizzo IP potrebbe non corrispondere alla regola di limitazione o di ban basata sulla frequenza. Per risolvere il problema, verifica che non ci siano errori nella condizione di corrispondenza, quindi modifica la condizione di corrispondenza della regola impostando il valore corretto.