Настройка .htaccess для полной безопасности

Аватар пользователя SkySofiaK SkySofiaK 9 февраля в 23:32

Я все настраиваю безопасность сайта и дошла до модуля Security Review, который мне показал такое *PHP files in the Drupal files directory can be executed.* Зайдя в справку, там мне показало, что файл .htaccess был изменен злоумышленниками, но насколько я знаю этот файл генерируется под сайт и хостинг (может и ошибаюсь). И вот я скачала самый новый файл .htacces с версии drupal-7.64 он действительно несколько изменен и дописан.

Вопросы, на которые я не имею понятия:

!) Как опридилиты действительно ли файл htaccess был изменен злоумышленниками?

2) Если файл .htaccess изменился по мере обновлений ядра Друпала, то как корректно добавить все новые правила?

3) Безопасно ли менять файл .htaccess например я пишет вот здесь http://blogerator.org/page/fajl-primery-htaccess-redirekt-dostup
21. Защищаем сайт?

0 Thanks

Лучший ответ

Аватар пользователя bsyomov bsyomov 10 февраля в 12:10

Надо запретить выполнение php, по крайней мере, в sites/*/files, а ещё лучше, оставить только нужные точки входа (/index.php, и что-то ещё по необходимости), и по возможности, это всё надо делать в конфигурации веб сервера, а не в .htaccess.

Комментарии

Аватар пользователя gun_dose gun_dose 10 февраля в 0:05

Можете скачать свежий друпал и посмотреть этот файл там, это даст вам ответ на 1 и 2 вопросы. По третьему вопросу: да, этот файл можно менять под свои нужды, примеры, как и зачем менять есть в самом этом файле. Главное при обновлении не затереть эти изменения.

По поводу "пхп филес мэй би экзекьютед" - тут недавно был спор на эту тему. В общем, суть в том, что по умолчанию друпал действительно позволяет выполнить по прямой ссылке любой пхп файл во внутренних директориях сайта. Именно эта возможность используется, когда при заражении сайта подкидывают левые файлы - их затем вызывают по прямой ссылке, а любители распаковать новую версию поверх старой не понимают, как их повторно взламывают. И вот суть в том, что секьюрити ревью вам всё верно говорит, лучше бы запретить исполнение таких файлов. Но это вам лучше обратиться к @bsyomov он в этом, наверное, лучше всех тут разбирается.

Тем не менее, в большинстве случаев этот момент практически все игнорируют. И в принципе это допустимо, т.к. чтобы этим воспользоваться, сперва нужно взломать сайт каким-либо другим способом.

Аватар пользователя bsyomov bsyomov 10 февраля в 12:10

Надо запретить выполнение php, по крайней мере, в sites/*/files, а ещё лучше, оставить только нужные точки входа (/index.php, и что-то ещё по необходимости), и по возможности, это всё надо делать в конфигурации веб сервера, а не в .htaccess.

Аватар пользователя gun_dose gun_dose 10 февраля в 12:41

За исключением очень редких случаев, нужно исполнять только index.php, install.php, cron.php и update.php. Вообще, если посмотреть в семёрке ядро и модули, то абсолютное большинство файлов с расширением .php - это .api.php, .tpl.php плюс классы в некоторых модулях. Все эти файлы не должны исполняться по прямой ссылке. Приблизительно такая ситуация в восьмёрке, только там значительно больше классов, а шаблоны вообще не php.

Аватар пользователя bsyomov bsyomov 10 февраля в 13:15
1

Да, я как раз об этом и писал.
При этом:
Файл install.php нужен только при установке.
Задачи выполняемые cron.php и update.php лучше запускать через drush, например, вне контекста веб сервера.
Т.е. и остаётся только одна точка входа - index.php, и возможно, что-то в модулях, например, это может быть какой-то обработчик статистики с упрощённым бутстрапом. Т.е. точки входа довольно легко контролируются.

Аватар пользователя VasyOK VasyOK 10 февраля в 0:12

1. [Виявити так] Посмотреть какой файл в дистрибутиве Друпала. Сравнить со своим. Изменен может быть не только файл htaccess, но и другие. Есть модуль hacked - он поможет выявить изменения.

2. Копируете htacess. Обновляете ядро. Возвращаете тот, что был. Вроде можно композер на это настроить. Делаем бекапы и спим спокойно. В самом htaccess авторами Друпала изменения редко проводятся. Если проводятся - врядли это повлияет на работу сайта.

3. Если пароль от файлов, БД и самого сайта знаете - меняйте что считаете нужным. Если еще куча народа - не поможет.

Аватар пользователя sas@drupal.org sas@drupal.org 10 февраля в 8:10

1) можно сравнить вплоть до автоматических средств типа diff
2) сравнить и перенести свои изменения
3) Часто меняется по необходимости, проблемы наступают например там где сервер не использует apache если использовать инструкции которые работают с ним.

Аватар пользователя SkySofiaK SkySofiaK 10 февраля в 13:24

Для начала я просто попробовала вставить все содержимое .htaccess с ядра друпал последней версии, то мне сразу выпала ошибка 500 ))))

Потом решила просто пересмотреть все правила и изучить их с новой версией друпал, там например заметила что правило *# Protect files and directories from prying eyes.* стало длиннее и там дописали **, и так далее

Вот ище вопрос по теме 21. Защищаем сайт по ссылке http://blogerator.org/page/fajl-primery-htaccess-redirekt-dostup
Я нашла в .htaccess Options +FollowSymLinks и там снизу дописала

*#Запускаем url_rewriting
RewriteEngine On
#Блокируем все ссылки, содержащие <script>
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
#Блокируем все скрипты, которые пытаются изменить переменные PHP Globals:
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
#Блокируем все скрипты, которые пытаются изменить переменную _REQUEST:
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
#Перенаправляем все подобные на страницу с ошибкой 403 — запрещено
RewriteRule ^(.*)$ index.php [F,L]*

правильно все сделала?

Аватар пользователя bsyomov bsyomov 10 февраля в 19:02

Нет.
1. Это просто не нужно. В принципе, менять стандартный .htaccess drupal, нет особого смысла, тем более дописывая туда всякий хлам. Кому-то показалось, что эти правила что-то улучшат, но увы, это совсем не так, фактически, представленные правила бесполезны чуть более чем полностью...

2. Это не совпадает с комментариями - перенаправление, в итоге, делается не на страницу 403, а на index.php зачем?

3. Советую изучать документацию, а не читать на сомнительных сайтах разные рецепты "сделать всё безопасно". 90% написанного просто бред, остальное просто применимо не везде, а в определённом частном случае, но об этом написать забыли. =)

Аватар пользователя SkySofiaK SkySofiaK 10 февраля в 19:33

Просветили ))) спасибо!!! А то я думала это какие то сильные защиты, ну судя по коментах к правилам.