Alcune o tutte le informazioni in questa pagina potrebbero non essere applicabili a Trusted Cloud di S3NS. Per ulteriori dettagli, consulta la sezione Differenze rispetto a Google Cloud.

Questa pagina è stata tradotta dall'API Cloud Translation.

Risolvi i problemi di Cloud Armor

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 nel criterio di sicurezza di Cloud Armor

Per risolvere il problema, segui questi passaggi:

Assicurati che la policy di sicurezza Cloud Armor sia collegata 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 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:

configuredAction deve corrispondere all'azione configurata nella regola.
name deve corrispondere al nome della policy di sicurezza Cloud Armor collegata a questo servizio di backend.
outcome deve corrispondere a configuredAction.
priority deve 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 describe su security-policies in Google Cloud CLI per visualizzare i contenuti dei criteri di sicurezza di 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
   --preview

Esamina i log HTTP(S) per i campi della richiesta HTTP, ad esempio url e cookie. Ad esempio, requestUrl ha 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 la regola OWASP CRS con ID 941180 aggiornandola nel criterio di sicurezza 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 \
    --preview

Esamina 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 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 di Cloud Armor applicato a valle impedirebbe alla richiesta di raggiungere il server di origine CDN.

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.

Passaggi successivi

Richiedere assistenza