Комментарии 76
Проще найти нормального(!) один раз админа, т.к. все равно какие-то вещи можно упустить. К тому же apache, лучше бы была связка LNPP :)
+3
Во-первых, найти нормального админа — это архи сложная задача. Особенно если админ вам нужен ровно на час — поднять веб-сервер с вашим сайтом. Что-то мне подсказывает, что большинство админов сделают aptitude install apache2.
Во-вторых — разворачивание LAMP — это некий стандартный процесс знакомства с администрированием. Все хотят развернуть LAMP и все гордятся, когда у них это получается. Пускай хоть не оставляют своим LAMP'ом дырень у себя в сервере, раз уж разворачивают. Да и заодно пускай призадумаются о безопасности.
Во-вторых — разворачивание LAMP — это некий стандартный процесс знакомства с администрированием. Все хотят развернуть LAMP и все гордятся, когда у них это получается. Пускай хоть не оставляют своим LAMP'ом дырень у себя в сервере, раз уж разворачивают. Да и заодно пускай призадумаются о безопасности.
+3
Иногда требуется поддержка .htaccess(например на shared хостинге).
Тут уже получится nginx+apache как минимум.
Тут уже получится nginx+apache как минимум.
+1
В эпоху chef и puppet мусолить тему о том, как тысячным способом поднять самый популярный в мире стек веб-технологий, как-то не комильфо)
+1
Опять?! Сколько еще админов тут не отписалось об сверхсложном apt-get?
+2
Где apt-get, какой apt-get? Вы бы хоть вступление прочитали, что ли. Эта статья, вообще-то, написана как раз под впечатлением от засилья админов, отписывающихся о сверхсложном apt-get. Или может вы тоже считаете, что достаточно просто написать apt-get и веб-сервер готов?
-2
НЛО прилетело и опубликовало эту надпись здесь
Поскольку мне как раз это будет нужно, может быть вы поделитесь как это делать?
+1
С itk меня всегда интересовал один вопрос: если запускать php от имени пользвоателя, которому принадлежит сайт, то php будет иметь права на запись во все файлы сайта. Что хреновенько. Если запускать от имени www-data, но с группой пользователя — тогда непонятно, зачем использовать itk. Получается, что для каждого сайта нужно создавать два пользователя — один для входа по (S)FTP, другой для апача, ну и одну группу. Я так и делал, когда использвоал itk. Но может я чего-то не догоняю?
-1
С itk меня всегда интересовал один вопрос: если запускать php от имени пользвоателя, которому принадлежит сайт, то php будет иметь права на запись во все файлы сайта. Что хреновенько.С точки зрения модели безопасности — всё нормально. Да, сайт пользователя могут поломать, зато другие пользователи гарантированно не пострадают. Кстати говоря, битовую маску доступа можно и через ftp/sftp менять. Только вряд ли кто-нибудь из пользователей «шареда» будет заморачиваться.
Получается, что для каждого сайта нужно создавать два пользователяМожно и одним пользователем обойтись. Сконфигурять mpm_itk для сайта так:
AssignUserId www-data usergroup
При этом EUID www-data доступа к файлам пользователя не дает вообще никакого. Поэтому можно разрешать/запрещать доступ исключительно правами группы. Только 99% пользователей этим заниматься не будет, даже если подробную инструкцию написать.
0
Меня всегда интересовал вопрос — а нет ли где-нибудь на официальных ресурсах полного списка с описанием всех PHP функций, которые так или иначе могут дать доступ скрипту к компонентам и файлам системы.Нет такого списка. Искал я как-то список функций, которые могут выполнить внешнюю программу, так даже и этого не нашлось. Есть вот такой перечень, и он не полный — там не хватает, как минимум, popen и pcntl_exec. А в твоем списке отсутствует самый обычный exec.
0
И, если задумать, есть ещё один вопрос: а вам не страшно запускать апач с полными root привилегиями, которые необходимы для работы itk? Что-то я начинаю сомневаться, что давая полного рута веб-серверу вы делаете его безопасней. Обход open_basedir и disable_functions не так страшен, как рут, разве нет? Вроде как itk не рекомендуют ставить на продакшен как раз потому, что он потенциально небезопасен. Хотя я хз, никогда плотно с itk не работал и в вопросе досконально не разбирался.
-1
Мне тут ссылочку кинули на этот пост, нас всех интересует один вопрос:
чем руководствовался ТС, когда прописывал временную директорию в веб-директории:
а потом закрывал в нее доступ? 0_о
P.S. «на всякий случай»?)
чем руководствовался ТС, когда прописывал временную директорию в веб-директории:
php_admin_value upload_tmp_dir /var/www/42/sites/deep-thought.net/temp
php_admin_value session.save_path /var/www/42/sites/deep-thought.net/temp
а потом закрывал в нее доступ? 0_о
<Directory /var/www/42/sites/deep-thought.net/temp>
AllowOverride None
Order Deny,Allow
Deny from All
P.S. «на всякий случай»?)
0
Оставить открытым доступ к tmp, где лежат сессии не самая лучшая идея, особенно если листинг каталогов включен.
0
Да ничем, если честно. Только тем, что пускай все файлы сайта лежат в одном месте, всё равно доступа туда нету. Тем паче что многие движки уже имеют эту temp (или tmp), ровно так же зарезанную с помощью .htaccess. Зачем сущности плодить?
-1
Использую похожую схему, только с nginx и php-fpm. Отличия:
— корень сайта ставлю как /var/www/username/example.com/{web,www,htdocs} — у многих фреймворков по дефолту в корне сайта лежат только файлы, к которым необходим доступ из веба (index.php и статика), а код фреймворка и приложения из веба недоступен и нет необходимости закрывать доступ к ним, tmp и прочим каталогам (например .git), более того как php обрабатывается только index.php, и даже если получится залить php файл на сайт, то выполнится он не сможет.
— nginx и php работают с правами пользователя аккаунта
— шелл по умолчанию есть у всех, деплой и обновления обычно через git идут
— корень сайта ставлю как /var/www/username/example.com/{web,www,htdocs} — у многих фреймворков по дефолту в корне сайта лежат только файлы, к которым необходим доступ из веба (index.php и статика), а код фреймворка и приложения из веба недоступен и нет необходимости закрывать доступ к ним, tmp и прочим каталогам (например .git), более того как php обрабатывается только index.php, и даже если получится залить php файл на сайт, то выполнится он не сможет.
— nginx и php работают с правами пользователя аккаунта
— шелл по умолчанию есть у всех, деплой и обновления обычно через git идут
+4
Запуск всех сайтов от одного юзера www-data это очень плохой совет. Автор, как это часто бывает, пишет о себе
Связка Nginx + php5-fpm с разграничением по юзерам даёт гораздо большую защищённость, а заодно и возможность гибкой конфигурации каждого сайта. То есть, одному можно включить open_basedr, другому php-apc.
Если кому интересен более безопасный способ запуска php — вот моя старая заметка.
А вот это — скрипт для добавления нового сайта, с автогенерацией паролей и созданием БД.
в этой статье я хотел показать фатальную недостаточность данных манипуляций и мягко говоря некомпетентность тех, кто их тиражирует в интернете.
Связка Nginx + php5-fpm с разграничением по юзерам даёт гораздо большую защищённость, а заодно и возможность гибкой конфигурации каждого сайта. То есть, одному можно включить open_basedr, другому php-apc.
Если кому интересен более безопасный способ запуска php — вот моя старая заметка.
А вот это — скрипт для добавления нового сайта, с автогенерацией паролей и созданием БД.
+16
Спасибо, кстати, за пост — помог в свое время разобраться.
+1
Спасибо. Очень полезная информация.
0
Спасибо, прочитал. Я упаси боже не утверждаю, что описанного в моей статье достаточно для правильного развёртывания полноценного боевого сайта. Я просто хотел показать, как поставив стандартную LAMP'у безо всяких там nginx, chroot для апача и прочего, настроить её хотя бы с намёком на безопасность. Вообще говоря в www-data нет ничего столь уж катастрофичного, в отличие от неуказания той же open_basedir или разрешения system().
А если вы посмотрите на опрос, то вы увидите, что многие даже так не делают. Какой уж там nginx…
А если вы посмотрите на опрос, то вы увидите, что многие даже так не делают. Какой уж там nginx…
-2
> Nginx + php5-fpm
Да хотя бы и апач с mpm_itk
Да хотя бы и апач с mpm_itk
0
А зачем снова, в очередной раз, обсуждать эту тему? Ведь эту статью точное также будут искать в гугле, если кому-то понадобится почитать данный материал. А в интернетах уж (как в русскоязычных, так и в англоязычных) тысячи подобных мануалов. У меня, собственно, только один вопрос — зачем, в очередной раз, разжевывать тему развёртывания сайта на linux-сервере? :)
+1
>> Меня всегда интересовал вопрос — а нет ли где-нибудь на официальных ресурсах
php.net/functions
>> полного списка с описанием всех PHP функций, которые так или иначе могут дать доступ скрипту к компонентам и файлам системы.
_все_ функции так или иначе имеют доступ к файлам и компонентам системы
php.net/functions
>> полного списка с описанием всех PHP функций, которые так или иначе могут дать доступ скрипту к компонентам и файлам системы.
_все_ функции так или иначе имеют доступ к файлам и компонентам системы
0
>> в этой статье я хотел показать фатальную недостаточность данных манипуляций и мягко говоря некомпетентность тех, кто их тиражирует в интернете.
Не буду громко заявлять о компетентности, но вот логика некоторых решений как минимум вызывает сомнения. Тот же велосипед с темпом в папке сайта, избыточный для пользователя SFTP (да, для него он избыточен) и пр.
Если уж начали говорить о минимальной безопасности — где FastCGI или ITK? Где нормальное разграничение пользователей?
В общем, автор хоть и пошёл чуть-чуть дальше, но всё равно неизбежно повторил путь сотен предшественников. Сам по себе, конечно, молодец, но вот зачем очередная бессмысленная статья об этом на хабре?
Не буду громко заявлять о компетентности, но вот логика некоторых решений как минимум вызывает сомнения. Тот же велосипед с темпом в папке сайта, избыточный для пользователя SFTP (да, для него он избыточен) и пр.
Если уж начали говорить о минимальной безопасности — где FastCGI или ITK? Где нормальное разграничение пользователей?
В общем, автор хоть и пошёл чуть-чуть дальше, но всё равно неизбежно повторил путь сотен предшественников. Сам по себе, конечно, молодец, но вот зачем очередная бессмысленная статья об этом на хабре?
+4
На опрос посмотрите — вот за этим. И нет, я мог бы написать очередную бессмысленную статью на тему nginx+php-fpm с БШ, мне же хотелось написть о стандартном LAMP безо всяких FastCGI и ITK. Потому что большинство ставит стандартный LAMP, использует стандартный LAMP и т.д. Тем, кто ставит itk, думается, никакие статьи не нужны.
-2
Понимаете, таких статей — их очень много. Самый элементарный запрос в гугль: «how to install lamp on my centos» выдает очень много ссылок на подобные руководства. К примеру, вот, первая же ссылка: www.howtoforge.com/installing-apache2-with-php5-and-mysql-support-on-centos-6.2-lamp
Всего же результатов было найдено порядка 1 690 000.
Всего же результатов было найдено порядка 1 690 000.
0
>> мне же хотелось написть о стандартном LAMP безо всяких FastCGI и ITK.
>> Потому что большинство ставит стандартный LAMP, использует стандартный LAMP
habrahabr.ru/post/158153/
habrahabr.ru/post/128698/
habrahabr.ru/post/20525/
habrahabr.ru/post/132302/
habrahabr.ru/post/64652/
Это я за минуту насобирал выдали поиска хабра по запросу «LAMP». Только хабра.
Да, очень оригинально.
>> Потому что большинство ставит стандартный LAMP, использует стандартный LAMP
habrahabr.ru/post/158153/
habrahabr.ru/post/128698/
habrahabr.ru/post/20525/
habrahabr.ru/post/132302/
habrahabr.ru/post/64652/
Это я за минуту насобирал выдали поиска хабра по запросу «LAMP». Только хабра.
Да, очень оригинально.
0
См. мой ответ выше.
-1
>> >> Если уж начали говорить о минимальной безопасности — где FastCGI или ITK? Где нормальное разграничение пользователей?
Где безопасность то? SFTP — это не безопасность. Это просто довольно экстравагантное решение в стандартной ситуации. SSH вообще на шареде давать нельзя.
Как к безопасности относится бессмысленно перемещённый темп, тоже не вполне понимаю. А всё остальное, в общем, «по канонам».
Где безопасность то? SFTP — это не безопасность. Это просто довольно экстравагантное решение в стандартной ситуации. SSH вообще на шареде давать нельзя.
Как к безопасности относится бессмысленно перемещённый темп, тоже не вполне понимаю. А всё остальное, в общем, «по канонам».
0
Хм, то есть FTP — это безопасность, а SFTP — уже нет. Интересная точка зрения. SFTP в любом случае безопасней FTP, а если вам так уж надо безопасности, что стандартных методов её обеспечения для SSH недостаточно, повесьте на сервере два демона SSH — один для пользователей хостинга, другой для админов. Ничего более безопасного я даже представить себе не могу. Пока что не слышал о фатальных уязвимостях в internal SFTP по ключу, позволяющих пользвоателю без ключа подключиться и получить какой-нибудь доступ к серверу. Хотя всё может быть…
temp перемещён не бессмысленно, а туда, где он уже есть у многих движков. Опять же — ничего суперкритичного в этом нет, спрятав temp вне корня сайта вы не закроете к нему доступ злоумышленников в случае взлома.
temp перемещён не бессмысленно, а туда, где он уже есть у многих движков. Опять же — ничего суперкритичного в этом нет, спрятав temp вне корня сайта вы не закроете к нему доступ злоумышленников в случае взлома.
0
Кто где говорил, что SFTP — это небезопасно? Просто довольно странная. Обычно для загрузки файлов пользователям хватает и обычного нешифрованного канала. Единственное интересное решение — ключи. Да, чтоб пароли не забывались. Но вы мне хоть одного среднего пользователя шареда покажите, который сможет сделать себе ключ и будет знать, как им пользоваться?
Плюс, SFTP поддерживают не все клиенты. В общем, я не говорю, что так менее безопасно. Как я выше уже написал — это просто экстравагантное решение.
>> temp перемещён не бессмысленно, а туда, где он уже есть у многих движков.
а у многих движков нет. Уж лучше какой-то стандартизации придерживаться и держать такие вещи в районе /tmp. А не городить очередной велосипед, за который админы, которым впоследствии, возможно, придётся это админить, будут костерить создателя по самое не балуйся.
Плюс, SFTP поддерживают не все клиенты. В общем, я не говорю, что так менее безопасно. Как я выше уже написал — это просто экстравагантное решение.
>> temp перемещён не бессмысленно, а туда, где он уже есть у многих движков.
а у многих движков нет. Уж лучше какой-то стандартизации придерживаться и держать такие вещи в районе /tmp. А не городить очередной велосипед, за который админы, которым впоследствии, возможно, придётся это админить, будут костерить создателя по самое не балуйся.
0
В районе /tmp — это очень странно. Если уж не в корне temp, то на уровень выше, но я всегда считал, что запихивать темп в системную помойку — это как раз нехорошо, не?
-1
Помнится возникали какие-то проблемы с /tmp при использовании open_basediir
0
Да не, нет никаких проблем — прописываем /tmp в open_basedir и всё. Правда в этом лсучае все сайты получат доступ к сессиям соседей — но проблем работоспособности, по крайней мере, не будет.
-1
Делаем нормальное разграничение правд для пользователей и всё нормально тут будет.
0
А зачем делать нормальное разграничение прав внутри директории, не предназначенной для разграничения прав? Не проще ли использовать всё же отдельные каталоги?
-2
Что значит «не предназначенной для разграничения прав»? Это как? Там запрещено выставлять нормальных владельцев для разграничения доступа?
единственная особенность /tmp — это то, что он после перезагрузки сервера очищается. И там не принято давать возможность не исполнение, т.к. директория доступна всем подряд на запись.
Но это никак не значит, что там нельзя нормально разграничить права на файлы.
В общем, ваша фраза «мягко говоря некомпетентность тех, кто их тиражирует в интернете.» вызывает всё большую и большую улыбку.
единственная особенность /tmp — это то, что он после перезагрузки сервера очищается. И там не принято давать возможность не исполнение, т.к. директория доступна всем подряд на запись.
Но это никак не значит, что там нельзя нормально разграничить права на файлы.
В общем, ваша фраза «мягко говоря некомпетентность тех, кто их тиражирует в интернете.» вызывает всё большую и большую улыбку.
+1
эм… «зачем делать нормальное разграничение».
Может быть для безопасности, о которой Вы пытались рассказать?
Может быть для безопасности, о которой Вы пытались рассказать?
0
>> повесьте на сервере два демона SSH — один для пользователей хостинга, другой для админов.
Может тогда уж для каждого пользователя отдельный SSH-демон заводить?:) Что уж капитальная секурность?:)
Может тогда уж для каждого пользователя отдельный SSH-демон заводить?:) Что уж капитальная секурность?:)
0
> стандартном LAMP безо всяких FastCGI и ITK
$ aptitude show apache2-mpm-itk/stable
Пакет: apache2-mpm-itk
Новый: да
Состояние: не установлен
Версия: 2.2.16-6+squeeze10
Приоритет: дополнительный
Раздел: net
… blablabla
В каком месте он нестандартный? Ах да, надо же при установке всего этого дела написать на целых 16 символов больше! Выпилить немедленно!
$ aptitude show apache2-mpm-itk/stable
Пакет: apache2-mpm-itk
Новый: да
Состояние: не установлен
Версия: 2.2.16-6+squeeze10
Приоритет: дополнительный
Раздел: net
… blablabla
В каком месте он нестандартный? Ах да, надо же при установке всего этого дела написать на целых 16 символов больше! Выпилить немедленно!
0
НЛО прилетело и опубликовало эту надпись здесь
И к слову о phpmyadmin — это, безусловно, классная вещь, но почти всегда вместо него хватит adminer. Один файл, легкость и быстрота, уменьшение потенциальной опасности взлома через свою, пока, относительную малораспространенность. Активно развивается, несколько более удобных фич, по сравнению с pma.
0
Кроме этого в приведённых выше настройках не отключена функция eval. Увы, многим сайтам она зачем-то нужна, хотя всё же лучше её отключать.
Автор, я последовал совету, отключил eval, но почему то не работает.
Подскажи, почему? Как мне быть?)
![image](https://habrastorage.org/getpro/habr/comment_images/d5c/a9e/c45/d5ca9ec4557a6c45f03b656227587786.jpg)
0
Статья неплоха, но все же явно необходимо поставить apache2-mpm-itk и настроить пользователей. Плюс закрыть phpmyadmin при помощи .htaccess — т.к. дико дырявая штуковина.
Кстати, кто реально использует libapache2-mod-apparmor — оно хоть как-то помогает?
Кстати, кто реально использует libapache2-mod-apparmor — оно хоть как-то помогает?
0
Когда вы закончите уже OpenNet.ru копипастить?
+9
Ну а апача то зачем? Я бы ещё понял, если какой-то mod_secirity использовался. Сейчас мейнстрим nginx с php-fpm на каждого юзверя свой процесс. Ну и всякие xcache в придачу.
+3
Apparmor использую. По крайней мере он прикрывает и дыры в самом PHP.
0
Может весьма нубский вопрос, но на CentOS есть некий защитный механизм SELinux. Мне все лень его изучить и во время настройки веб-сервера было много с ним проблем, по этому пришлось отключить.
Вот мне собственно интересно, он влияет на защищенность самого веб-сервера или только оси?
Кстати, большое спасибо за статью и отдельное спасибо за комментарии в коде, очень познавательно.
Вот мне собственно интересно, он влияет на защищенность самого веб-сервера или только оси?
Кстати, большое спасибо за статью и отдельное спасибо за комментарии в коде, очень познавательно.
0
>> Для всех пользователей SFTP основной группой будет установлена www-data (дефолтная группа Apache2 в deb-based). Кроме этого, все создаваемые как пользователем по SFTP, так и Apache, файлы по умолчанию будут иметь права 0660, а каталоги — 0770. Поскольку у Apache и SFTP пользователя одна и та же группа, то по-умолчанию в любой новый файл или каталог сможет писать как пользователь, так и веб-сервер, вне зависимости от того, кто его создал. Что обычно и требуется.
Вот это странно, на мой взгляд.
Вот это странно, на мой взгляд.
0
Заранее прошу прощения за глупый вопрос. Я вот все это сделал, правда на убунте, а у меня – Write failed: Broken pipe, для этого юзера. Вот что в логах:
fatal: bad ownership or modes for chroot directory component "/var/www/dir_name/"
Что я сделал не так? Буду очень благодарен.
fatal: bad ownership or modes for chroot directory component "/var/www/dir_name/"
Что я сделал не так? Буду очень благодарен.
0
так а в dirname вы никогда ничего и не создадите) Там надо создавать ещё один каталог, на который уже выставлять желаемые права.
0
Про ACL, кстати, никто и ничего так и не припомнил =)
0
Безопасность LAMP-стека? Расскажите нам про SELinux и AppArmor.
0
Забавно. Сначала не работала заливка по sftp. С шеллом /bin/false sftp не мог авторизоваться. Если оставить /bin/bash — авторизация проходит и можно заливать файлы. Но и войти через ssh нельзя, судя по всему, т.к. в конфиге sshd стоит «ForceCommand internal-sftp» для группы.
Интересно, почему в посте именно /bin/false, с которым sftp не работает?
Интересно, почему в посте именно /bin/false, с которым sftp не работает?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
И снова о… LAMP и базово защищённый мини-хостинг своими руками