Настройка безопасности Drupal веб-сервера. Права доступа к файлам drupal

Права на файлы/папки Drupal / Тяпк

Веб-сервер должен иметь возможность читать нужные файлы, но не писать в них. Другие пользователи не должны иметь доступа к сайту. Если сайт включает в себя загрузку файлов, серверу даётся разрешение писать только в одну папку.

TLDR

В скобках указывается смягчённый вариант.

Все папки - 750 (755), все файлы 640 (644)
/sites/default - 550 (750)
/sites/default/settings.php - 440 (444)
/sites/default/files включая подпапки - 770(775), файлы 660(664). Другие решения представлены ниже.

Более подробно

Как и в других web проектах, в drupal большинство папок имеют права 750(755), а файлы 640(644). Чтобы присвоить такие права выполняются команды, находясь в корне drupal проекта:

sudo chown -R site_admin:www-data * sudo find . -type d -exec chmod 750 {} \; sudo find . -type f -exec chmod 640 {} \;

Для работы Drupal требуется база данных, конфигурация БД хранится в файле settings.php в папке sites/default (Drupal 6, 7 и 8).

После установки и настройки сайта на Drupal папка sites/default должна иметь права 550 (чтение/выполнение) [dr-xr-x---], а файл settings.php - 440 (только чтение) [-r--r-----]. Drupal по завершению установки пытается сам поставить такие права и если это не удалось, то следует права выставить вручную:

chmod 550 sites/default chmod 440 sites/default/settings.php # либо chmod a-w sites/default # либо chmod a-w sites/default/settings.php

Для загрузки файлов в sites/default/files надо папке назначить группу веб-сервера (www-data для apache), если это не было сделано.

chgrp -Rv www-data sites/default/files

Проблема с папкой files на базе Apache

Если папка files не во владении группы веб-сервера, то рассматривается 2 способа дать возможность веб-серверу загружать в неё файлы. На unix системах можно узнать под каким пользователем работает веб-сервер.

ps aux | grep apache

Команда выдаст подобный результат

apache_user 36610 0.0 0.0 18832 2340 0 S+ 6:42PM 0:00.00 grep apache

В первом столбце будет пользователь веб-сервера. В рассматриваемом случае пользователь - apache_user. Чтобы сделать папку доступной для записи, необходимо сделать такого пользователя владельцем этой папки:

chown -R apache_user sites/default/files

Если нет прав на изменение владельца папки, то следующее решение это установка прав записи на папку для группы. Делается командой:

chmod -R 0770 sites/default/files

Скрываем версию Drupal

Распространено мнение, что скрытие установленной версии CMS усложняет взлом системы. Чтобы усложнить задачу идентифкации версии, достаточно удалить файлы документации или сделать их недоступными для чтения. В первую очередь это касается файла CHANGELOG.txt. Для каждого из скрываемых файлов вызывается следующая команда.

chmod a-r <filename>

Почитать самостоятельно

tyapk.ru

Настройка безопасности Drupal веб-сервера | drupal-admin.ru

Настройка FIREWALL

Итак, наш веб-сервер управляется ОС Debian, и нам необходимо обезопасить его, настроить всё так, чтобы свести все риски к минимуму. Для начала, выполняем базовую настройку Firewall. Наш выбор - IPTables.

Изначально фаервол открыт, весь трафик проходит через него беспрепятственно. Список правил iptables мы проверяем следующей командой:

# iptables -L -v -n Chain INPUT (policy ACCEPT 5851 packets, 7522K bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 320M packets, 19G bytes) pkts bytes target prot opt in out source destination

Всё ясно. Удаление всех правил из IPTables осуществляется следующей командой:

iptables -F

Правила по умолчанию IPTables

Правила по умолчанию -- удобная и полезная вещь. В IPTables они задаются с помощью политик (-P). Обычная практика -- отбрасывание всех пакетов и ряд разрешающих правил конкретных случаев.

Отбрасывать (блокировать) все пакеты позволяет следующее правило:

iptables -P INPUT DROP

Дополнительное усиление защиты -- запрет пересылаемых пакетов, то есть пакетов, маршрутизируемых брандмауэром к точке назначения. Этот уровень защиты включается следующим правилом:

iptables -P FORWARD DROP

Для loopback мы разрешаем локальный трафик:

iptables -A INPUT -i lo -j ACCEPT

В следующем правиле используется модуль (-m) state. Он позволяет проверить состояние устанавливаемого соединения, которое может быть RELATED или ESTABLISHED. Соединение устанавливается только тогда, когда оно удовлетворяет настройкам правила. Состояние ESTABLISHED указывает на то, что в рамках соединения уже пересылались пакеты, состояние RELATED -- на то, что пересылкой пакета устанавливается новое соединение, но оно связано с уже существующим соединением.

Следующее правило разрешает работу всех уже инициированных соединений (ESTABLISHED) и дочерних по отношению к ним:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

А это правило допускает и новые соединения:

iptables -A OUTPUT -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

Данное правило разрешает форвардинг новых, существующих (инициированных) и их дочерних соединений:

iptables -A FORWARD -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

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

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP

Разрешающие правила

Следующий шаг: определяем разрешающие правила, обеспечивающие корректную работу нашего веб-сервера. Их мы оформляем отдельной цепочкой.

Создаём пользовательские цепочки:

iptables -N my_packets

Переход в пользовательскую цепочку осуществляется следующей командой:

iptables -A INPUT -p tcp -j my_packets

Есть ряд ограничений, накладываемых на движение по цепочкам

цепочка должна быть создана до того, как на неё выполняется переход;
цепочка должна находиться в той же таблице, что и цепочка, с которой происходит переход.

Далее мы открываем порт для ssh. Важно: обязательно укажите свой порт, если ранее он был изменён!

iptables -A my_packets -p tcp -m tcp --dport 22 -j ACCEPT

Если подключение по ssh позволено только некоторым лицам, имеющим статические ip адреса, есть смысл настроить ограничение по ip адресам. Чтобы сделать это, мы вместо предыдущей команды используем такую:

iptables -A my_packets -s х.х.х.х -p tcp -m tcp --dport 22 -j ACCEPT

где х.х.х.х - ip адрес, с которого выполняется подключение.

Так как у нас работает веб-сервер, мы должны открывать порты 80 и 443. Для этого используем следующие команды:

iptables -A my_packets -p tcp -m tcp --dport 80 -j ACCEPT iptables -A my_packets -p tcp -m tcp --dport 443 -j ACCEPT

В дополнение ко всем этим правилам, можно настроить ряд правил для следующих случаев:

Удалённое подключение к серверу MySQL Если такое возможно, лучше ограничивать подключение по ip адресам: iptables -A my_packets -s х.х.х.х -p tcp -m tcp --dport 3306 -j ACCEPT
Сервер настроен на прием почты Для такого случая хорошо иметь следующий набор правил: iptables -A my_packets -p tcp -m tcp --dport 110 -j ACCEPT iptables -A my_packets -p tcp -m tcp --dport 143 -j ACCEPT iptables -A my_packets -p tcp -m tcp --dport 993 -j ACCEPT iptables -A my_packets -p tcp -m tcp --dport 995 -j ACCEPT

Всё. Этих правил достаточно, чтобы наш веб-сервер корректно работал. Для остальных портов и протоколов настраиваем REJECT, то есть не принимаем ничего:

iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable

От DROP эта директива отличается тем, что отправитель получает IСМР-сообщение "Port unreachable" («Порт недоступен»). Опция --reject-with позволяет изменить тип ICMP-сообщения и имеет следующие аргументы:

icmp-net-unreachable — сеть недоступна;
icmp-host-unreachable — узел недоступен;
icmp-port-unreachable — порт недоступен;
icmp-proto-unreachable — неподдерживаемый протокол;
icmp-net-prohibited — сеть запрещена;
icmp-host-prohibited — узел запрещен.

По умолчанию передаётся сообщение с аргументом port-unreachable.

TCP-пакеты можно отклонить с помощью аргумента tcp-reset, он подразумевает отправку RST-сообщения. С точки зрения безопасности, это наилучший способ. TCP RST пакеты используются для закрытия TCP соединений.

2. Настройка fail2ban

Fail2ban — простой локальный сервис, отслеживающий log–файлы запущенных программ. Руководствуясь условиями, сервис блокирует по IP обнаруженных нарушителей.

Fail2ban успешно справляется с различными атаками на все популярные *NIX–сервисы (Apache, Nginx, ProFTPD, vsftpd, Exim, Postfix, named и т.д.) Так же Fail2ban защитает SSH–сервер от bruteforce-атак прямо “из коробки”.

Установка fail2ban

Fail2ban есть в репозитории, так что установить его очень просто:

apt-get install fail2ban

Настройка Fail2ban

В первую очередь, необходимо настроить защиту сервера по протоколу SSH. Для начала, найдите в файле jail.conf секцию [ssh] и убедитесь в том, что в значении параметра enabled фигурирует true.

Затем следует указать значения параметров fail2ban:

filter — используемый фильтр. По умолчанию это /etc/fail2ban/filter.d/sshd.conf;
action — действия, выполняемые fail2ban, когда обнаружен атакующий ip-адрес; описания правил реагирования атаки есть в файле /etc/fail2ban/action.d., то есть значение параметра не может быть таким, которого нет в этом файле;
logpath — полный путь к файлу, в который записывается записываются данные о попытках получения доступа к VPS;

findtime — время (в секундах), в течение которого фиксируется подозрительная активность;
maxretry — максимальное разрешенное количество попыток подключения к серверу;
bantime — время блокировки попавшего в черный список ip.

Важно: прописывать все параметры необязательно, если вы не сделаете этого, будут действовать настройки, указанные в главном разделе [DEFAULT]. Главное -- указать для переменной enabled значение true.

Защита протокола SSH

Рассмотрим применение параметров реагирования в деталях. Ниже -- пример конфигурации fail2ban на порту SSH:

[ssh] enabled = true port = ssh filter = sshd action = iptables[name=sshd, port=ssh, protocol=tcp] sendmail-whois[name=ssh, dest=****@yandex.ru, sender=fail2ban@***.ru] logpath = /var/log/auth.log maxretry = 3 bantime = 600

Расшифровка: если выполнено более 3 неудачных попыток подключения к серверу через порт SSH, то ip-адрес, с которого выполнялась авторизация, блокируется на 10 минут. Правило запрета добавляется в IPTables, а владелец сервера получает уведомление на адрес, указанный в переменной dest. В уведомлении -- заблокированный ip, WHOIS-данные об этом ip и причина блокировки.

Дополнительно, для защиты SSH можно активировать следующую секцию:

[ssh-ddos] enabled = true port = ssh filter = sshd-ddos logpath = /var/log/auth.log maxretry = 2

3. Настройка прав доступа к файлам сайта

Сервер нельзя считать безопасным, если не выполнена настройка прав доступа к файлам Drupal сайта. Приведённый ниже пример -- один из способов изменения владельца и прав на файлы/каталоги Drupal-сайта. Вводные:

webmaster принадлежит группе webmaster и является владельцем сайта;
сам сайт находится на сервере, где веб-сервер работает под пользователем www-data.

Настраиваем права:

#cd /path_to_drupal_installation #chown -R webmaster:www-data . #find . -type d -exec chmod u=rwx,g=rx,o= '{}' \; #find . -type f -exec chmod u=rw,g=r,o= '{}' \;

Пользователь www-data должен иметь права на запись в директорию, поэтому у директории «files» в каталоге sites/default (и у любых других каталогов сайтов, если установка многосайтовая) разрешения различные. Бит s группы владельца используется и для каталога, так как нам надо, чтобы все файлы, созданные в нем веб-сервером, принимали идентификатор группы каталога webmaster, а не группы владельца, создавшего файл в этом каталоге.

#cd /path_to_drupal_installation/sites #find . -type d -name files -exec chown -R www-data:webmaster '{}' \; #find . -type d -name files -exec chmod ug=rwx,o=,g+s '{}' \; #for d in ./*/files do find $d -type d -exec chmod ug=rwx,o=,g+s '{}' \; find $d -type f -exec chmod ug=rw,o= '{}' \; done

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

#cd /path_to_drupal_installation #chown -R www-data:webmaster tmp #chmod ug=rwx,o=,g+s tmp

settings.php и .htaccess: особые права

Файл settings.php содержит пароль базы данных и имя пользователя, причём указаны они там простым текстом. Так что после его создания, надо установить такие права, которые позволяют чтение только определённым пользователям. Обычно, необходимо просто лишить прав пользователя «other»:

#chmod 440 './sites/*/settings.php' #chmod 440 './sites/*/default.settings.php'

.htaccess - конфигурационный файл Apache, дающий власть над работой веб-сервера и настройками сайта. Соответственно, права должны допускать чтение только определёнными пользователями:

#chmod 440 './.htaccess' #chmod 440 './tmp/.htaccess' #chmod 440 './sites/*/files/.htaccess'

4. Безопасная настройка ssh

Чтобы сделать систему более защищённой, рекомендую внести некоторые изменения в настройки сервера SSH. Лучше запускать его на нестандартном порту, иначе к нему постоянно будут обращаться боты, в том числе подбирающие пароли. В Debian, как и в других дистрибутивах Linux, SSH по умолчанию работает на порту 22. Можно изменить его на, скажем, 2223. Кроме того, стоит изменить конфигурацию так, чтобы root подключался только с использованием ssh ключа. По умолчанию, в Debian пользователь root по SSH не может пройти авторизацию паролем.

Лучше изменять порт SSH до настройки firewall. Если же вы не сделали это, надо выполнить следующие действия:

Перед сменой порта SSH добавьте в IPTables правило, разрешающие подключение по новому порту

iptables -A my_packets -p tcp -m tcp --dport 2223 -j ACCEPT

Измените порт сервера SSH в /etc/ssh/sshd_config. Там нужно изменить соответствующие строки, чтобы они выглядели так:

Port 2223 PermitRootLogin prohibit-password PubkeyAuthentication yes ChallengeResponseAuthentication no

Не забудьте сохранить изменения! Затем перезапустите SSH-сервер:

# service sshd restart

Тут можно и нужно проверить изменения:

# netstat -tulnp | grep ssh tcp 0 0 0.0.0.0:2223 0.0.0.0:* LISTEN 640/sshd tcp6 0 0 :::2223 :::* LISTEN 640/sshd

Всё в порядке. SSH-сервер слушает порт 2223, теперь новое подключение будет осуществляться только через этот порт, а после перезапуска SSH старое подключение не будет разорвано.

Внимание! Перед отключением авторизации по паролю для пользователя root проверьте, есть ли в файле /root/.ssh/authorized_keys ваш открытый ключ.

drupal-admin.ru

Роли и права доступа | Drupal learning

В предыдущем уроке мы рассмотрели раздел администрирования пользователей, а в этом уроке мы рассмотрим вторую его часть Права доступа (Permissions).

Для того чтобы перейти в этот раздел нажмите на вкладку Права доступа в разделе Пользователи как показано на рисунке:

Ссылка на раздел Права доступа

На странице Права доступа мы видим большую матрицу с настройками прав доступа для каждой из ролей.

Настройки прав доступа

Рассмотрим эту страницу более детально. Первая колонка Право доступа содержит перечень различных прав доступа предоставляемых установленными модулями и другими частями системы, напротив каждого права доступа содержатся чекбоксы для каждой из ролей. На данный момент у нас на сайте присутствует три роли созданных по умолчанию:

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

Прав подступа очень много и их становится еще больше при установке новых модулей, потому что каждый модуль может объявлять свои права доступа, поэтому мы не будем рассматривать каждое право доступа в отдельности.

Теперь переходим в раздел управления ролями:

Ссылка на страницу редактирования ролей

В этом разделе мы можем создавать, удалять и редактировать роли и права доступа для ролей. Для примера создадим роль Редактор, для этого заполним форму добавления роли и нажмем кнопку Добавить роль как показано на картинке ниже:

Теперь когда у нас есть новая роль дадим ей несколько прав доступа нажав на ссылку Редактировать права доступа как показано на картинке ниже:

Настройка прав доступа для роли

На этой странице нам представлена такая-же таблица с правами доступа, только не для всех ролей сразу а только для выбранной роли Редактор, это упрощает редактирование и повышает читабельность формы.

Настройка прав доступа для роли

Дадим этой роли права создавать новые материалы типа Новость и редактировать свои созданные новости:

После окончания редактирования формы нажимаем кнопку Сохранить права доступа.

Теперь назначим эту роль нашему пользователю test и посмотрим что изменилось. Переходим на страницу редактирования учетной записи пользователя test, в разделе Роли ставим галочку напротив роли Редактор.

Нажимаем кнопку Сохранить.

Теперь в списке пользователей мы видим что пользователь test имеет роль Редактор:

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

Теперь зайдя на сайт под пользователем test мы видим что для него стала доступна ссылка Добавить содержимое.

Ссылка Добавить содержимое

Перейдя по этой ссылке пользователь имеющий роль Редактор может создать новость.

Создание новости

После создания новости видно что ее автором является test, а также ему доступна возможность редактирования созданной им новости.

На этом мы завершаем наш последний урок в этом курсе. Если вам что-то осталось не ясно пишите ваши вопросы в комментарии.

drupal-learning.com

Конфигурация локального хоста и проблема с правами доступа к файлам Drupal Ask

Всякий раз, когда я работаю на своей локальной машине, я почти всегда испытываю проблемы, связанные с настройками прав доступа к файлам, и, поскольку я думаю, они могут быть связаны с моей локальной конфигурацией машины, я хотел бы объяснить, как я ее настроил, чтобы получить советы о том, как настройте его должным образом (поскольку мои знания о конфигурации сервера довольно ограничены, и я далек от того, чтобы быть системным администратором).

Моя локальная машина использует ubuntu как ОС, и я устанавливал php5, php5-mysql, mysql-server, apache2 и phpmyadmin отдельно, используя пакеты ubuntu. Единственная настраиваемая конфигурация, которую я сделал, заключается в том, что я не размещаю сайты в папке etc/apache2/www по умолчанию, а в конкретной папке на моем домашнем разделе ~/www . Чтобы эти настройки были выполнены, я должен выполнить следующие действия:

Я редактирую /etc/apache2/sites-enabled/000-default чтобы указать на эту папку, заменив /var/www на путь к ~/www
Перезапустить apache ( sudo /etc/init.d/apache2 restart )
Создайте символическую ссылку внутри ~/www которая указывает на /usr/share/phpmyadmin ( # ln -s /usr/share/phpmyadmin /home/carlos/www/phpmyadmin )

Эта конфигурация имеет следующие преимущества, которые мне очень важны:

Я могу сохранить свой код в безопасности, когда я устанавливаю новую версию ubuntu (это каждые шесть месяцев), но в то же время я могу форматировать / разделять без потери каких-либо данных.
Мне не нужны дополнительные разрешения (sudo) каждый раз, когда я хочу редактировать любой файл (что часто, так как это моя среда разработки), модули обновления и т. Д.

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

Есть ли способ предотвратить проблемы с правами доступа к файлам, а также предотвратить размещение файлов в папке etc/apache2/www ?

Solutions Collecting From Web of "Конфигурация локального хоста и проблема с правами доступа к файлам"

Для работы веб-сервера должна быть правильно настроенная файловая структура. Файлы должны быть помещены под / var / www или / usr / local, а не под / home. Каталог / etc предназначен для файлов системы и конфигурации, а не файлов веб-данных.

Не должно быть оснований для форматирования корневого раздела при обслуживании системы, но если вы настаиваете на этом, поместите / var / usr и / home на отдельный диск и смонтируйте их под корнем во время загрузки. Таким образом, вы не потеряете никаких данных.

Если вы так отчаянно хотите облегчить редактирование, работайте как root и научитесь быть осторожными. Но убедитесь, что файлы находятся под правильной группой и владельцем веб-сервера.

У меня есть решение для сервера Apache localhost (Linux Mint) (только для локальных тестов).

Вам нужно изменить пользователя и группу для Apache на локальное имя пользователя (например, greg).

/ И т.д. / apache2 / envvars:

экспорт APACHE_RUN_USER = greg

экспорт APACHE_RUN_GROUP = greg

Перезапустите Apache.

Apache не должен писать ни в какие файлы или каталоги, если вы явно не разрешаете изменять права собственности или разрешения, если это необходимо, например, сайты / файлы по умолчанию / файлы. На общедоступном сайте все остальное будет представлять собой огромный риск для безопасности.

Некоторым людям нравится запускать apache как собственный пользователь для удобства, но IMO лучше знать, какие каталоги нужны для разрешения записи, чтобы вы могли реплицировать их в своей производственной среде.

Один из возможных ответов, которые я нашел для решения проблем с drupal, используя эту конфигурацию, – это изменение владельца и группы для sites/default папки по sites/default для www-data таким образом, не будет никакой проблемы, когда drupal хочет создать стили изображений, кеш css или js, создавать временные файлы, прикреплять файлы … которые являются общими проблемами, которые я нашел, но, с другой стороны, я смогу редактировать файлы без sudo-разрешений и быть в состоянии форматировать / по своему желанию, не теряя ничего.

drupal.wordpressask.com