Utilizza queste istruzioni per risolvere i problemi relativi alla sicurezza di Google Cloud Armor criteri.
Problemi generici
Debug dei criteri di sicurezza
Se hai bisogno di ulteriori informazioni sugli attivatori di eventi specifici su regole preconfigurate, leggi Utilizzo del logging delle richieste. e poi attivare il logging dettagliato. Cloud Logging registra un livello più elevato dettagli nei log, che puoi utilizzare per analizzare ed eseguire il debug dei tuoi criteri le regole del caso.
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 restituito deve includere il nome del criterio di sicurezza di Google Cloud Armor associati a questo servizio di backend.gcloud compute backend-services describe BACKEND
Esamina i log HTTP(S) per determinare per quale criterio e regola è stata trovata una corrispondenza per il traffico insieme all'azione associata. Per visualizzare i log, utilizza Cloud Logging.
Di seguito è riportato un esempio di log di una richiesta consentita con i campi interessanti in evidenza. Verifica i seguenti campi e assicurati che corrispondano ai che hai configurato per negare il traffico:
configuredActiondeve corrispondere all'azione configurata nella regola.namedeve corrispondere al nome del criterio di sicurezza di Google Cloud Armor collegato 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 soddisfatta la regola corretta. it è possibile che una regola di priorità più alta con un'azione di autorizzazione corrisponda al tuo per via del traffico. Utilizza il comando
describesusecurity-policiesin Google Cloud CLI per visualizzare i contenuti della sicurezza di Google Cloud Armor .Ad esempio, l'esempio seguente mostra come una regola di autorizzazione con priorità più alta (con priorità 100) corrisponde al traffico proveniente dall'indirizzo IP 1.2.3.4, impedendo alla regola di negazione a priorità inferiore (con priorità 200) l'attivazione e il blocco il traffico.
gcloud compute security-policies describe POLICY_NAME
Uscita:
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 delle firme statiche su Intestazioni delle richieste HTTP e altri parametri L7. Queste espressioni regolari modelli sono inclini a falsi positivi. Puoi utilizzare la regola preconfigurata per Rilevamento di XSS e SQLi in modalità di anteprima e controllo della presenza nel log di eventuali errori positivi.
Se trovi un falso positivo, puoi confrontare i contenuti del traffico con
Regole CRS ModSecurity.
Se la regola non è valida o non è pertinente, disattivala utilizzando la proprietà
evaluatePreconfiguredExpr e specifica l'ID della regola nell'espressione
exclude ID list argomento.
Dopo aver esaminato i log e rimosso tutti i falsi positivi, disabilita l'anteprima .
Per aggiungere una regola preconfigurata in modalità di anteprima:
Crea un criterio di sicurezza con l'espressione preconfigurata impostata in anteprima modalità:
gcloud compute security-policies rules create 1000 --security-policy POLICY_NAME --expression "evaluatePreconfiguredExpr('xss-stable')" --action deny-403 --previewEsamina i log HTTP(S) per Campi di richiesta HTTP come
urlecookie. Ad esempio,requestUrlconfronta positivamente con l'ID regola CRS 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 di 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, quindi disattiva la modalità di anteprima per implementare la regola.
I client con firme negate non vengono bloccati né rifiutati
Se utilizzi Google Cloud Armor con Cloud CDN, i criteri vengono applicati solo per richieste di contenuti dinamici, fallimenti della cache o altre richieste destinate al server di origine CDN. Gli hit della cache sono anche se il criterio di sicurezza downstream di Google Cloud Armor che la richiesta non raggiunga il server di origine CDN.
Minimizzare il rischio per il corpo POST superiore a 8 kB quando si utilizzano regole WAF preconfigurate
Quando una regola WAF preconfigurata viene valutata in un ambiente di sicurezza Google Cloud Armor viene controllato un massimo di 8 kB del corpo POST per verificare la presenza di corrispondenze della firma le regole WAF. Questo approccio fornisce l'ispezione e il livello 7 a bassa latenza garantendo al contempo la disponibilità per gli altri clienti Google.
Per ridurre il rischio derivante da richieste POST più grandi, crea una regola nel per assicurarti che nessun contenuto non controllato raggiunga i tuoi backend. Crea una regola per negare il traffico superiore a 8 kB (8192 byte) nelle dimensioni del corpo 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 risolvere i problemi relativi agli indirizzi IP denominati elenchi.
Indirizzi IP all'interno di un elenco di indirizzi IP denominati
Gli indirizzi IP negli elenchi corrispondono sempre agli indirizzi IP nel provider siti web elencati nell'elenco Guida agli elenchi di indirizzi IP denominati di Google Cloud Armor. Se hai domande su gli elenchi, contatta il team dell'assistenza di Cloud.
Gli indirizzi IP all'interno di un elenco di indirizzi IP denominati sono inattivi in Google Cloud Armor
Google Cloud Armor sincronizza i propri elenchi con i provider degli elenchi di indirizzi IP ogni giorno. È possibile che i dati non siano aggiornati con un ritardo di alcune ore o un giorno per trasferire i dati presso un provider. 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à nella creazione di un criterio di sicurezza che fa riferimento a un elenco di indirizzi IP denominato
Potresti provare a creare un criterio di sicurezza che faccia riferimento a un indirizzo 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 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 provider specifico sia supportato e che il nome dell'IP
sia specificato correttamente. Puoi verificarlo utilizzando:
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 denominata
Potresti scoprire che il traffico è bloccato da un indirizzo IP che si trova su un Elenco indirizzi IP:
Assicurati che il traffico provenga da un indirizzo IP che si trova su una lista consentita di indirizzi IP con nome.
Controlla se esistono altre regole di sicurezza con una priorità più elevata che possono bloccare il traffico. Se il problema persiste, contatta il team di assistenza di Cloud.
Assicurati che il criterio di sicurezza sia collegato al backend corretto servizio:
gcloud compute backend-services describe BACKEND_SERVICE
Controlla le regole incluse 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 predefinita di negazione, regola di autorizzazione per Indirizzi IP di Fastly e un server per un referrer che contiene
altostrat. Le rispettive vengono elencate anche le 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" } …Dal log precedente, la richiesta proviene da
23.230.32.10, che è coperto dall'elenco di indirizzi IP pubblici di Fastly. Tuttavia, alla richiesta viene abbinata una regola di negazione di un priorità pari a 50. Confrontando questo valore con i contenuti del criterio di sicurezza, la regola corrisponde alla regola di negazione per un referer che contienealtostrat. Poiché la richiesta ha un referrer dihttp://www.altostrat.com/, l'applicazione forzata 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, verso i servizi di backend potrebbe non soddisfare i criteri per generare un ricerca.
Per domande sul volume di traffico verso i tuoi backend, consulta le statistiche delle richieste in le dashboard di Cloud Monitoring nella sezione Sicurezza di rete Norme.
I risultati sono troppo rumorosi
Per ricevere assistenza in merito a questo problema, contatta il team di assistenza di Cloud.
Problemi con Google Cloud Armor Adaptive Protection
Usa queste istruzioni per risolvere i problemi relativi a Adaptive Protection.
Adaptive Protection è abilitato per un criterio di sicurezza, ma non ci sono log in Cloud Logging
I log di Adaptive Protection vengono generati separatamente da Google Cloud Armor log delle richieste e vengono visualizzati in un'altra risorsa in Cloud Logging. I log e gli eventi di Adaptive Protection si trovano nella sezione Network Security (Sicurezza di rete) Policy in Cloud Logging. Il periodo di addestramento è di almeno ora dopo l'abilitazione di Adaptive Protection in un criterio di sicurezza prima Adaptive Protection inizia a generare avvisi per gli attacchi sospetti. Durante durante il periodo di addestramento, Adaptive Protection apprende dalle richieste in entrata il traffico e sviluppa basi distinte per ogni servizio di backend protette da tali criteri di sicurezza. Adaptive Protection successivamente può per identificare le attività sospette.
Se abiliti Adaptive Protection per un criterio di sicurezza e non osservare eventuali avvisi dopo un periodo di addestramento di un'ora, ciò suggerisce Nessuna attività che possa essere identificata come targeting potenzialmente dannoso di uno qualsiasi degli ai servizi di backend associati al criterio di sicurezza.
Se il potenziale attacco o traffico anomalo persiste per periodi più lunghi di superiore a diverse ore, Adaptive Protection inizia a ritenere che come comportamento di base e non continua a inviare avvisi su traffico simile pattern. Una volta che il potenziale attacco cessa e i modelli di traffico tornano la base di riferimento originale, perché l'attacco si è concluso o l'hai bloccato con le regole appropriate di Google Cloud Armor, gli avvisi di Adaptive Protection sui comportamenti futuri del traffico considerati deviazioni dalla base di riferimento.
Adaptive Protection analizza il traffico che altrimenti sarebbe consentito attraverso un criterio di sicurezza di Google Cloud Armor. Se imposti la regola predefinita in modo che nega l'accesso con una lista consentita di traffico limitata, quindi Adaptive Protection rileva solo le attività dannose sul traffico che supera la valutazione con rispetto alla lista consentita.
Troppi avvisi o troppi log in Cloud Logging di Adaptive Protection
Un avviso di Adaptive Protection fornisce un punteggio di confidenza, che indica il I modelli di Adaptive Protection identificano l'attività rilevata e potenzialmente un attacco. Puoi filtrare in base alla voce specifica del log attraverso Cloud Logging solo per visualizzare (o inoltrare al downstream) gli avvisi con un punteggio di confidenza superiore a una determinata soglia.
Adaptive Protection fornisce un meccanismo per segnalare gli avvisi come falsi positivi, descritta nella sezione Monitoraggio, feedback e report eventi. Tieni presente che la segnalazione di falsi positivi potrebbe non comportare modifiche agli avvisi di Adaptive Protection. Nel tempo, I modelli di Adaptive Protection apprendono che questi pattern di traffico sono normali accettabile e Adaptive Protection smette di ricevere avvisi per questi pattern.
Se gli avvisi di Adaptive Protection sono troppo frequenti su un sottoinsieme di backend di sicurezza in un criterio di sicurezza, è possibile che questi servizi di backend il traffico normale presenta fluttuazioni significative che vengono costantemente identificate Adaptive Protection come comportamenti anomali. Puoi creare un modello criterio di sicurezza senza Adaptive Protection abilitato e associali di backend con il nuovo criterio di sicurezza.
Un particolare 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 di errori correlati agli eventi. Tieni presente che le segnalazioni di falsi positivi potrebbero non comportare modifiche immediate a ciò che Avvisi di Adaptive Protection attivi. Nel tempo, Adaptive Protection modella apprendono che questi modelli di traffico sono normali e accettabili e Adaptive Protection smette di inviare avvisi su questi pattern.
Come posso sapere che i miei criteri di sicurezza perimetrale vengono applicati?
Puoi controllare le azioni intraprese sui criteri di sicurezza perimetrali mediante il dashboard di monitoraggio, metriche di monitoraggio o logging per richiesta.
Dashboard di Monitoring
Cloud Monitoring è disponibile nei Criteri di sicurezza della rete in Monitoring. Puoi usare la suddivisione per criterio di sicurezza su della pagina per misurare il numero di richieste consentite e rifiutate dalla il criterio di sicurezza perimetrale configurato. Puoi anche esaminare la suddivisione per backend per eseguire il debug di un particolare servizio di backend. Per maggiori dettagli sui alla dashboard di Cloud Monitoring, Monitoraggio dei criteri di sicurezza di Google Cloud Armor.
Monitoraggio delle metriche
Le metriche non elaborate che misurano le richieste consentite e negate sono disponibili per il perimetro criteri di sicurezza. Per ulteriori informazioni, vedi Monitoraggio delle metriche per i criteri di sicurezza.
Logging per richiesta
La decisione del criterio di sicurezza perimetrale viene registrata nei log delle richieste di bilanciamento del carico
sotto enforcedEdgeSecurityPolicy. Questo è separato dal
enforcedSecurityPolicy, che acquisisce la decisione relativa al criterio di sicurezza del backend.
Gestione di bot
Questa sezione contiene informazioni sulla risoluzione dei problemi relativi al bot gestione dei dispositivi.
Gli utenti non sono esentati come previsto
Potresti aver configurato regole del criterio di sicurezza con l'azione di reindirizzamento per test reCAPTCHA e scoprire che alcuni utenti che ritieni siano legittimi non sono stati esentati come previsto. Segui questi passaggi per risoluzione dei problemi.
Innanzitutto, controlla nei log delle singole richieste se è presente un criterio di sicurezza.
con una priorità più alta che corrisponde al traffico, in cui l'azione viene
diverso. In particolare, cerca i campi configured_action e outcome.
Tieni presente che, affinché un utente sia esente, sono necessarie almeno due richieste. La
la richiesta iniziale viene fornita senza un cookie di esenzione, mentre le richieste successive
vengono forniti con un cookie di esenzione se l'utente supera il reCAPTCHA.
la valutazione. Pertanto, sono previste almeno due voci di log.
- Se vedi
GOOGLE_RECAPTCHAcome azione configurata eREDIRECTcome azione l'esito, la richiesta è stata reindirizzata per test reCAPTCHA; - Se vedi
GOOGLE_RECAPTCHAcome azione configurata eACCEPTcome azione il risultato, la richiesta è stata esente dal reindirizzamento per Test reCAPTCHA. - Se nei campi precedenti sono riportati valori diversi, viene applicata una regola con un è stata trovata una corrispondenza. In questo caso, ci si aspetta che l'utente non reindirizzato o esente.
In secondo luogo, gli utenti devono soddisfare diversi requisiti esonerato dal reindirizzamento per test reCAPTCHA.
- L'utente deve utilizzare un browser.
- Il browser deve attivare JavaScript per consentire il corretto caricamento del reindirizzamento con reCAPTCHA JavaScript incorporato.
- Il browser deve abilitare i cookie per consentire l'impostazione e l'associazione automatica il cookie di esenzione.
- L'utente deve superare test reCAPTCHA. Ad esempio, è necessario risolvere le eventuali verifiche popup.
Gli utenti che non possono soddisfare i requisiti di cui sopra non ricevono l'esenzione, anche se una regola con l'azione di reindirizzamento per Test reCAPTCHA corrisponde.
Terzo, test reCAPTCHA viene eseguita solo quando il reindirizzamento viene visualizzata la pagina che incorpora il codice JavaScript reCAPTCHA. Per questo motivo, il reindirizzamento per test reCAPTCHA è applicabile solo per le richieste che prevedono una risposta che porti a visualizzare l'intera pagina. Altro come il caricamento di asset all'interno di una pagina o le richieste derivanti da un script incorporato che non prevede la visualizzazione della risposta, non sono previsti per ottenere test reCAPTCHA. Pertanto, ti consigliamo di presentare domanda questa azione con una condizione di corrispondenza per i percorsi degli URL che soddisfano questa condizione.
Ad esempio, supponiamo che tu abbia una pagina web che contiene elementi incorporati come immagini, link ad altre pagine web e script. Non vuoi applicare azione di reindirizzamento per test reCAPTCHA per i percorsi degli URL che ospitano immagini o che dovrebbero essere accessibili agli script in cui viene visualizzata una pagina intera non è previsto. Puoi invece applicare l'azione di reindirizzamento per Test reCAPTCHA per i percorsi degli URL che ospitano pagine web, come pagina web principale o altre pagine web collegate.
Infine, se la pagina di reindirizzamento viene visualizzata correttamente, controlla nella sezione Strumento fornito dal browser per verificare se è stato impostato un cookie di esenzione se è allegato nelle richieste successive per lo stesso sito. Per ulteriori informazioni puoi contattare l'assistenza Cloud dell'IA.
Problemi con la limitazione di frequenza
Il traffico non è limitato come previsto
Potresti scoprire che un indirizzo IP client invia alti livelli di traffico a un dell'applicazione a una velocità superiore alla soglia impostata, ma il traffico è non è limitata come previsto. Segui questi passaggi per esaminare il problema.
In primo luogo, verifica se una regola di priorità più elevata consente il traffico proveniente da quell'IP
. Esamina i log per verificare se è stata attivata una regola ALLOW per l'IP
. Potrebbe trattarsi di una regola ALLOW a sé stante, in un'altra THROTTLE o
RATE_BASED_BAN.
Se trovi una regola di priorità più alta, esegui una delle seguenti operazioni:
- Modifica le priorità per garantire che la regola di limitazione di frequenza abbia un la priorità, assegnandole un valore numerico inferiore.
- Escludi l'indirizzo IP dall'espressione corrispondente nella regola che ha un una priorità più elevata.
Il problema potrebbe anche essere un'impostazione errata della soglia. Se questo è il le richieste vengono abbinate con precisione, ma viene attivata l'azione di conformità. Esamina i log per confermare che è così, poi riduci la soglia in la regola.
Infine, l'indirizzo IP potrebbe non corrispondere alla regola di limitazione o di esclusione basata sulla frequenza. A per risolvere il problema, verifica che non ci sia un errore nella condizione di corrispondenza, poi modifica la condizione di corrispondenza al valore corretto.