Nginx відключає .htaccess і приховані файли, але дозволяє. Добре відомий каталог

16

У мене є сервер Nginx і вимкнено приховані файли в nginx_vhost.conf

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

Але LetsEncrypt потребує доступу до .well-knownкаталогу.

Як дозволити .well-knownкаталог і заборонити інші приховані файли?

nginx virtualhost lets-encrypt

— Janghou
джерело

Примітка: nginx не використовує .htaccessфайли. У ньому є файли конфігурації, але вони не називаються .htaccessі не працюють однаково.

— Роб

17

Інші рішення мені не допомогли.

Моє рішення - включити від'ємний регулярний вираз для .well-known. Ваш код коду повинен виглядати наступним чином:

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

Він заблокує кожен файл точок, крім тих, що починаються з .well-known

PS: Я також хотів би додати return 404;до блоку.

— therealmarv
джерело

1

Є , location ~* /\.(?!well-known\/) {як видно на github.com/h5bp/server-configs-nginx/blob/master/h5bp/location / ... ідентичний цього location ~ /\.(?!well-known).* { ?

— Pro Backup

3

ні, це не зовсім точно. /\.(?!well-known\/)не настільки виразний, як мій регулярний вираз (тому що я блокую всі крапкові файли, крім відомих за визначенням). Можливо, найкращим було б таке поєднання, location ~ /\.(?!well-known\/).*яке розблокує лише відомий каталог, а не теоретичний .well-known-blabla. Але я думаю, що немає реальної небезпеки не заблокувати теоретичний. Добре відомий файл blabla.

— therealmarv

чому відключити htaccess, оскільки так чи інакше Nginx не справляється з цим?

— Веб-жінка

3

Так, ти правий @webwoman, але іноді є змішане середовище. На мій погляд, будь-який крапковий файл не повинен подаватися (безпека чи небажане викриття історії, як, наприклад, з .git), якщо насправді це не потрібно.

— therealmarv

16

Nginx застосовує місця з регулярними виразами в порядку їх появи у файлі конфігурації.

Тому додавши такий запис безпосередньо перед поточним місцеположенням, він допоможе вам.

location ~ /\.well-known { 
    allow all;
}

— Вейрдей
джерело

Дякую, це саме те, що мені було потрібно! Розміщують це перед правилом, що забороняє доступ до всіх точкових файлів. Єдине, що я змінив, - це уникнути крапки, наприклад location ~ /\.well-known {. Так чи інакше, це повинна бути прийнята відповідь.

— aexl

8

Я надав повний покроковий посібник про те, як використовувати Let's Encrypt з NGINX на своєму веб-сайті.

Ключові частини:

Офіційний клієнт лише добре, і він дуже поганий в Amazon Linux. Я рекомендую іншого клієнта, ACME .
Використовуйте це місце для методу webroot з моїм рекомендованим клієнтом. Зауважте, що запити надсилаються через http, а не https.

Вам не потрібні слухачі у вашому https-блоці, це все робиться на https. Це лише для того, щоб довести, що ви керуєте доменом, він не служить нічого приватного чи секретного.

# 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;
  }
}

Повний покроковий посібник, зв'язаний вище.

— Тім
джерело

3

Додайте це (до або після):

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

Ви можете додати це також внизу, оскільки ^~модифікатор відповідності має перевагу над регулярними виразами. Дивіться документи .

— Janghou
джерело

0

Якщо у вас багато конфігураційних файлів, вони вже містять заборону на .htaccess на зразок

location ~ /\.ht { deny all; }

тоді замість ігнорування всіх точкових файлів ви можете просто додати друге ігнорування для .git з

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

— rubo77
джерело