Nginx deaktiviert .htaccess und versteckte Dateien, erlaubt aber ein bekanntes Verzeichnis

16

Ich habe einen Nginx-Server und deaktiviere versteckte Dateien in der nginx_vhost.conf

## Disable .htaccess and other hidden files
    location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }

LetsEncrypt benötigt jedoch Zugriff auf das .well-knownVerzeichnis.

Wie kann ich das .well-knownVerzeichnis zulassen und die anderen versteckten Dateien verweigern?

nginx virtualhost lets-encrypt Janghou
quelle
Hinweis: Nginx verwendet oder hat keine .htaccessDateien. Es hat Konfigurationsdateien, die aber nicht aufgerufen werden .htaccessund auch nicht gleich funktionieren.
Rob

Antworten:

17

Die anderen Lösungen haben mir nicht geholfen.

Meine Lösung besteht darin, einen negativen regulären Ausdruck für aufzunehmen .well-known. Ihr Codeblock sollte dann so aussehen:

## Disable .htaccess and other hidden files
location ~ /\.(?!well-known).* {
    deny all;
    access_log off;
    log_not_found off;
}

Es wird jede Punktedatei mit Ausnahme derjenigen blockiert, die mit beginnen .well-known

PS: Ich würde return 404;den Block auch ergänzen .

therealmarv
quelle
1
Ist location ~* /\.(?!well-known\/) {wie unter github.com/h5bp/server-configs-nginx/blob/master/h5bp/location/… zu sehen identisch location ~ /\.(?!well-known).* { ?
Pro Backup
3
nein es ist nicht dasselbe genau. /\.(?!well-known\/)ist nicht so aussagekräftig wie mein regulärer Ausdruck (weil ich alle Punktedateien außer den per Definition bekannten blockiere). Vielleicht wäre das Beste eine Kombination wie location ~ /\.(?!well-known\/).*die, die nur das bekannte Verzeichnis freischaltet, stattdessen auch ein theoretisches .well-known-blabla. Aber ich denke, es besteht keine wirkliche Gefahr, eine theoretische .well-known-blabla-Datei nicht zu blockieren.
Therealmarv
warum htaccess deaktivieren, da Nginx sowieso nicht damit umgeht?
Webwoman
3
Ja, du hast recht @webwoman, aber manchmal gibt es gemischte Umgebungen. Jegliche Punktedatei sollte meiner Meinung nach nicht zugestellt werden (Sicherheit oder ungewolltes Aufdecken des Verlaufs wie bei .git), es sei denn, dies wird wirklich benötigt.
Therealmarv
16

Nginx wendet Speicherorte mit regulären Ausdrücken in der Reihenfolge ihres Auftretens in der Konfigurationsdatei an.

Daher hilft es Ihnen , einen Eintrag wie diesen direkt vor Ihrem aktuellen Standort hinzuzufügen .

location ~ /\.well-known { 
    allow all;
}
Weirdei
quelle
Danke, genau das habe ich gebraucht! Stellte dies vor eine Regel, die den Zugriff auf alle Punktedateien verweigert. Das einzige, was ich geändert habe, war dem Punkt zu entkommen, z location ~ /\.well-known {. In jedem Fall sollte dies die akzeptierte Antwort sein.
Aexl
8

Ich habe eine vollständige schrittweise Anleitung zur Verwendung von Let's Encrypt mit NGINX auf meiner Website bereitgestellt .

Die Schlüsselteile sind:

  • Der offizielle Client ist nur in Ordnung und unter Amazon Linux wirklich schlecht. Ich empfehle einen anderen Kunden, ACME .
  • Verwenden Sie diesen Speicherort für die Webroot-Methode mit meinem empfohlenen Client. Beachten Sie, dass die Anforderungen über http und nicht über https bereitgestellt werden.

Sie brauchen überhaupt keine Listener in Ihrem https-Block, es wird alles über https erledigt. Dies soll nur beweisen, dass Sie die Domain kontrollieren. Es wird nichts Privates oder Geheimes bereitgestellt.

# Answer let's encrypt requests, but forward everything else to https
server {
  listen       80;
  server_name  example.com www.example.com
  access_log  /var/log/nginx/access.log main;

  # Let's Encrypt certificates with Acmetool
  location /.well-known/acme-challenge/ {
    alias /var/www/.well-known/acme-challenge/;
  }

  location / {
    return       301 https://www.example.com$request_uri;
  }
}

Vollständige Schritt-für-Schritt-Anleitung, die oben verlinkt ist.

Tim
quelle
3

Füge dies hinzu (vorher oder nachher):

location ^~ /.well-known/ {
        log_not_found off;
     }

Sie können dies auch unten hinzufügen, da der entsprechende ^~Modifikator Vorrang vor regulären Ausdrücken hat. Siehe die Dokumentation .

Janghou
quelle
0

Wenn Sie viele Konfigurationsdateien haben und diese bereits einen Verweigerungscode für .htaccess wie enthalten

location ~ /\.ht { deny all; }

dann stattdessen alle Punkt - Dateien zu ignorieren , können Sie einfach hinzufügen , eine zweite für .git ignorieren mit

sed -i '/location ~ \/\\.ht { deny all; }/a \  location ~ \/\\.git { deny all; }' /etc/nginx/*
rubo77
quelle