LINUX.ORG.RU

Nginx. Запретить доступ к служебным папкам и файлам с выдачей нормальной 404

 ,


0

1

Привет всем. От этот nginx уже мозги закипают... На новом хостинге сделал всё, поднял виртуальные хосты, всё работает. Хочется немного странного.

А именно - защитить «служебные» папки сайта и файлы в них от просмотра посетителями, не нарушив функциональность сайта.

Поясню. Например, есть папка site/images/, в которой хранятся все изображения, применяющиеся в дизайне сайта.

Во-первых, если набрать site/images/real-name.jpg, то получим на экране real-name.jpg, чего не хотелось бы.

Во-вторых. Вот если набрать в адресной строке какую-нибудь фигню типа /site/ssfgrtdg, то выдаётся нормальная 404.php, со всеми картинками и т.п. Если же набрать имя одной из реально существующих папок, выдаётся та же 404.php, но чисто текстом, без стилей и картинок. Почему - непонятно.

Причём вообще происходит что-то странное. После ряда экспериментов с локейшеном /images/ сейчас по site/images выдаётся нормальная 404, хотя в данный момент всё в этой секции закомментировано. Я не знаю, может, rewrite permanent подейстовало, но факт остаётся фактом. Всё закомменчено, а 404 нормальная. Правда, прямой доступ к файлам в папке остался.

С прочими папками пока такая фигня, как описано выше - 404 без стилей и картинок.

В общем, вопрос. Как правильно решить эту задачу? Чтобы посетители не могли просматривать файлы, получая нормальную 404, и при этом сайт работал, сам получая файлы из /images? Заранее благодарен за ответы. If any...

PS Ещё одна дополнительная проблема. Когда набираем имя существующей папки и получаем вот эту текстовую 404, ссылки с неё работают в контексте этой папки. Т.е., например, набрали /site/files, получили кривую 404. Нажимаем на ней ссылку «на главную» и получаем не site/index.php, а site/files/index.php

Тоже хотелось бы устранить. Впрочем, логика подсказывает, что у этих двух проблем одно решение.

Если эти файлы участвуют в дизайне сайта, видимого посетителями, то нефиг их закрывать, тогда и дизайн накроется одним местом.

heilkitty ★★ ()

Ещё одна дополнительная проблема. Когда набираем имя существующей папки и получаем вот эту текстовую 404, ссылки с неё работают в контексте этой папки. Т.е., например, набрали /site/files, получили кривую 404. Нажимаем на ней ссылку «на главную» и получаем не site/index.php, а site/files/index.php

Ссылка на главную должна быть абсолютной. Т.е.

href="/"
, а не
href=""
. URL'ы к листам стилей тоже абсолютными:
href="/site/files/style.css"
. Подозреваю, у тебя такой фигни на сайте ещё полно, так что лучше пофиксь её, а не занимайся ерундой типа 404.

heilkitty ★★ ()

Если тебе так уж сильно подгадить пользователям в плане просмотра тех картинок, погугли «nginx disable hotlinking». Или проверяй на HTTP Referer. Пусть это и не совсем то, что тебе хотелось.

heilkitty ★★ ()

Я бы, использовал CGI скрипты и возможно AJAX. Тогда служебные каталоги и файлы точно не видны будут.

anonymous ()

Нафига? Можно конечно скриптом каждый раз вытаскивать файл из одной папки в другую читать и удалять его уже там но зачем? Безопасность это не увеличит.

Raptor ()
Ответ на: комментарий от anonymous

AJAX от дотошных человеков не спасёт.

anonymous ()
Ответ на: комментарий от heilkitty

Ну хорошо, допустим.

Но почему при наборе в адресной строке http://site/всякая_фигня показывается нормальная 404, а при наборе http://site/реальная_папка - кривая 404 без картинок и стилей?

Причём, ситуация такая. Это всё я делаю на новом хостинге, с нуля. На старом, например, всё несколько по-другому. Т.е., при наборе http://site/всякая_фигня также выдаётся нормальная 404, а при наборе http://site/реальная_папка - встроенная 404 nginx.

Messir ()
Ответ на: комментарий от heilkitty

Поймите меня правильно: я не веб-дизайнер, я системный администратор.

Ссылки в тексте страниц поправить, конечно, смогу. Только я не совсем понял. В секции server есть директива root /home/user/www, которая задаёт путь к корню сайта. Как в этом случае должен выглядеть абсолютный путь? Кстати, ссылки на сайте заданы как «/index.php», например (это ссылка на главную). И ещё кстати: в конфиге nginx в той же секции server задано: error_page 404 = /404.php

Где-то здесь есть ошибка?

Messir ()
Ответ на: комментарий от Messir

Но почему при наборе в адресной строке http://site/всякая_фигня показывается нормальная 404, а при наборе http://site/реальная_папка - кривая 404 без картинок и стилей?

Это надо глядеть в результирующий html-код, какие там URL получаются. Во втором случае они явно получились не те. Так что надо глядеть в 404.php, какой там путь к css-ке, в частности.

а при наборе http://site/реальная_папка - встроенная 404 nginx.

Там, по-видимому, не было

error_page 404 = /404.php

heilkitty ★★ ()
Ответ на: комментарий от heilkitty

Спасибо, что отвечаете.

Что ещё меня смущает, так это поведение папки /images, с которой проводились эксперименты. (Кстати, она выбрана именно просто для экспериментов. У меня не стоит цели как-то «нагадить пользователям». Моя задача - чтобы всё работало корректно и было максимально безопасно. Прежде мне доводилось работать с хостингами, но не поднимать их с нуля. Просто на прошлом хостинге был такой бедлам, что оказалось проще переехать, чем разгребать там авгиевы конюшни.)

Так вот, после очередной перезагрузки nginx теперь по http://site/images/ выдаётся стандартная 403 Forbidden. При этом доступ к файлам внутри папки есть.

%)

То есть, я ещё работал с правами доступа к файлам, но это применялось ко всем файлам и папкам. А с прочими пока ситуация прежняя: кривая 404.

Messir ()
Ответ на: комментарий от heilkitty

УПД. Посмотрел исходный код. Похоже, Вы правы. Есть ссылка, обозначенная как /forum, и по ней переход корректный. Остальные УРЛы без слеша. В том числе и пути к css и картинкам. Спасибо.

Остаётся один вопрос: как быть с этой злосчастной /images? Подозреваю, нужно просто убрать локейшн из конфига...

Messir ()
Ответ на: комментарий от Messir

теперь по http://site/images/ выдаётся стандартная 403 Forbidden. При этом доступ к файлам внутри папки есть.

В nginx по умолчанию запрещены индексы каталогов. Данное поведение нормальное и стандартное.

heilkitty ★★ ()
Ответ на: комментарий от heilkitty

Ещё раз спасибо за подсказку о путях. Только вот... Если для стилей и картинок было достаточно поставить слэш в начале, то со ссылками это не помогает. Оно всё равно пытается открыть /site/images/index.php и т.д.

И что же делать? Неужели прописывать всё внешними ссылками? Мне кажется, это неправильно...

Messir ()
Ответ на: комментарий от Messir

Пардон, ошибся. Всё работает, как Вы и сказали.

Большое спасибо за помощь!

Messir ()
Ответ на: комментарий от anonymous

Ещё как надо, а то ведь текст украдут.
Ещё можно гифки повесить и сделать нескучный фон.

Sense ()

Во-первых, если набрать site/images/real-name.jpg, то получим на экране real-name.jpg, чего не хотелось бы.

если сильно надо, то способ есть.
можно на сайте картинку показывать, а по директ-линку - запрещать.
для этого нужно проверять Referer.

ну или раз тема в webdev, можно так: включать картинки с src=/my-own-script-for-images.php?imgcode=XXX и затем в своем скрипте проверяй что-хочешь - referer, данные пользовательской сессии, юзерагента, делай кастомные ACL в базе и т.д. реальные ссылки на картинки тоже храни в базе, вытягивай по передаваемому imgcode и отдавай редирект, а в nginx настрой internal-локацию http://wiki.nginx.org/HttpCoreModule#internal

Komintern ★★★★★ ()
Последнее исправление: Komintern (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.