2013-10-09 7 views
8

Ich benötige Zugriffsprotokolle aktiviert, aber aus Compliance-Gründen können die Daten eines sensiblen GET-Anforderungsparameters nicht in den Zugriffsprotokollen protokolliert werden. Während ich weiß, konnte ich die Protokolle analysieren (nach der Tat) und sie bereinigen, das ist keine akzeptable Lösung - weil aus Gründen der Compliance Logs nicht manipuliert werden können.Wie protokolliere ich einen get-Request-Parameter nicht in den nginx-Zugriffsprotokollen?

http://www.example.com/resource?param1=123&sensitive_param=sensitive_data

Wie kann ich den „sensitive_data“ Parameterwert verhindern, in die Protokolle geschrieben werden? Hier waren ein paar Ideen:

  • POST-Anfrage senden - ist keine Option mit JSONP.
  • Verwenden Sie eine neue Standortregel für "Ressource" und legen Sie ein Zugriffsprotokoll fest, um ein log_format zu verwenden, das ein anderes Format verwendet (dh $ remote_addr nicht verwendet). Sehen Sie dieses als Referenz: http://nginx.org/en/docs/http/ngx_http_log_module.html
  • Melden Sie ein $ sanitized_remote_addr, und stellen Sie es ein (irgendwie parse das $ remote_addr oder etwas anderes?), Bevor es es zum Protokoll macht. Wir sind nicht sicher, ob dies leicht zu erreichen ist.

Wie soll das gemacht werden?

+1

Sie könnten auch in Betracht ziehen [mod_security für nginx] (http://www.modsecurity.org/projects/modsecurity/nginx/) und einen Blick am [naxsi-Projekt] (https://github.com/nbs-system/naxsi) –

Antwort

1

Die Lösung, die ich bisher gefunden habe, ist here. Kurz gesagt:

location /any_sensitive... { 
    # Strip password in access.log 
    set $temp $request; 
    if ($temp ~ (.*)password=[^&]*(.*)) { 
     set $temp $1password=****$2; 
    } 

    log_format filter '$remote_addr - $remote_user [$time_local] ' 
     '"$temp" $status $body_bytes_sent "$http_referer" "$http_user_agent"'; 

    access_log logs/access.log filter; 
} 

Vielleicht hat dies irgendwann arbeiten, jetzt heißt es:

nginx: [emerg] unknown "temp" variable 

oder

nginx: [warn] the "log_format" directive may be used only on "http" level in ... 
+0

Vielleicht, wenn es nur ein/zwei Protokolldateien ist, können Sie Pipes verwenden und die Ausgabe mit einem Filter bereinigen, der auf diesen abhört. Der Filter kann dann die echten Protokolldateien schreiben. –

+3

Nein, Sie haben es richtig, solange Sie die Variable irgendwo eingestellt haben, sollte sich nginx nicht über eine unbekannte Variable beschweren. Ich habe Ihre Antwort in eine funktionierende Lösung umgesetzt, die hier beschrieben wird: https://github.com/sunlightlabs/congress/tree/master/config/nginx#suppressing-user-latituutelongitude-in-our-logs – Konklone

4

vorherige Antwort wird nicht funktionieren, da log_format Modul nur dann verwendet werden kann unter http level config.

Zur Behebung dieses Problems können wir die log_format Konfiguration aus der location Direktive entfernen und sie wie in http level config beibehalten.

http { 

    log_format filter '$remote_addr - $remote_user [$time_local] ' 
     '"$temp" $status $body_bytes_sent "$http_referer" "$http_user_agent"'; 

    # Other Configs 
} 

log_format Richtlinie können Variablen später in unserem location Richtlinie Block definiert haben.

So endgültige Konfiguration wird wie folgt aussehen:

http { 

    log_format filter '$remote_addr - $remote_user [$time_local] ' 
     '"$temp" $status $body_bytes_sent "$http_referer" "$http_user_agent"'; 

    # Other Configs 

    server { 
     #Server Configs 
     location/{ 
      set $temp $request; 
      if ($temp ~ (.*)password=[^&]*(.*)) { 
       set $temp $1password=****$2; 
      } 

      access_log /opt/current/log/nginx_access.log filter; 
     } 
    } 
}