Comments 76
Проще найти нормального(!) один раз админа, т.к. все равно какие-то вещи можно упустить. К тому же apache, лучше бы была связка LNPP :)
Во-первых, найти нормального админа — это архи сложная задача. Особенно если админ вам нужен ровно на час — поднять веб-сервер с вашим сайтом. Что-то мне подсказывает, что большинство админов сделают aptitude install apache2.
Во-вторых — разворачивание LAMP — это некий стандартный процесс знакомства с администрированием. Все хотят развернуть LAMP и все гордятся, когда у них это получается. Пускай хоть не оставляют своим LAMP'ом дырень у себя в сервере, раз уж разворачивают. Да и заодно пускай призадумаются о безопасности.
Во-вторых — разворачивание LAMP — это некий стандартный процесс знакомства с администрированием. Все хотят развернуть LAMP и все гордятся, когда у них это получается. Пускай хоть не оставляют своим LAMP'ом дырень у себя в сервере, раз уж разворачивают. Да и заодно пускай призадумаются о безопасности.
Иногда требуется поддержка .htaccess(например на shared хостинге).
Тут уже получится nginx+apache как минимум.
Тут уже получится nginx+apache как минимум.
В эпоху chef и puppet мусолить тему о том, как тысячным способом поднять самый популярный в мире стек веб-технологий, как-то не комильфо)
Опять?! Сколько еще админов тут не отписалось об сверхсложном apt-get?
UFO just landed and posted this here
Поскольку мне как раз это будет нужно, может быть вы поделитесь как это делать?
С itk меня всегда интересовал один вопрос: если запускать php от имени пользвоателя, которому принадлежит сайт, то php будет иметь права на запись во все файлы сайта. Что хреновенько. Если запускать от имени www-data, но с группой пользователя — тогда непонятно, зачем использовать itk. Получается, что для каждого сайта нужно создавать два пользователя — один для входа по (S)FTP, другой для апача, ну и одну группу. Я так и делал, когда использвоал itk. Но может я чего-то не догоняю?
С itk меня всегда интересовал один вопрос: если запускать php от имени пользвоателя, которому принадлежит сайт, то php будет иметь права на запись во все файлы сайта. Что хреновенько.С точки зрения модели безопасности — всё нормально. Да, сайт пользователя могут поломать, зато другие пользователи гарантированно не пострадают. Кстати говоря, битовую маску доступа можно и через ftp/sftp менять. Только вряд ли кто-нибудь из пользователей «шареда» будет заморачиваться.
Получается, что для каждого сайта нужно создавать два пользователяМожно и одним пользователем обойтись. Сконфигурять mpm_itk для сайта так:
AssignUserId www-data usergroupПри этом EUID www-data доступа к файлам пользователя не дает вообще никакого. Поэтому можно разрешать/запрещать доступ исключительно правами группы. Только 99% пользователей этим заниматься не будет, даже если подробную инструкцию написать.
Меня всегда интересовал вопрос — а нет ли где-нибудь на официальных ресурсах полного списка с описанием всех PHP функций, которые так или иначе могут дать доступ скрипту к компонентам и файлам системы.Нет такого списка. Искал я как-то список функций, которые могут выполнить внешнюю программу, так даже и этого не нашлось. Есть вот такой перечень, и он не полный — там не хватает, как минимум, popen и pcntl_exec. А в твоем списке отсутствует самый обычный exec.
И, если задумать, есть ещё один вопрос: а вам не страшно запускать апач с полными root привилегиями, которые необходимы для работы itk? Что-то я начинаю сомневаться, что давая полного рута веб-серверу вы делаете его безопасней. Обход open_basedir и disable_functions не так страшен, как рут, разве нет? Вроде как itk не рекомендуют ставить на продакшен как раз потому, что он потенциально небезопасен. Хотя я хз, никогда плотно с itk не работал и в вопросе досконально не разбирался.
Мне тут ссылочку кинули на этот пост, нас всех интересует один вопрос:
чем руководствовался ТС, когда прописывал временную директорию в веб-директории:
а потом закрывал в нее доступ? 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. «на всякий случай»?)
Оставить открытым доступ к tmp, где лежат сессии не самая лучшая идея, особенно если листинг каталогов включен.
Да ничем, если честно. Только тем, что пускай все файлы сайта лежат в одном месте, всё равно доступа туда нету. Тем паче что многие движки уже имеют эту temp (или tmp), ровно так же зарезанную с помощью .htaccess. Зачем сущности плодить?
Использую похожую схему, только с 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 идут
Запуск всех сайтов от одного юзера www-data это очень плохой совет. Автор, как это часто бывает, пишет о себе
Связка Nginx + php5-fpm с разграничением по юзерам даёт гораздо большую защищённость, а заодно и возможность гибкой конфигурации каждого сайта. То есть, одному можно включить open_basedr, другому php-apc.
Если кому интересен более безопасный способ запуска php — вот моя старая заметка.
А вот это — скрипт для добавления нового сайта, с автогенерацией паролей и созданием БД.
в этой статье я хотел показать фатальную недостаточность данных манипуляций и мягко говоря некомпетентность тех, кто их тиражирует в интернете.
Связка Nginx + php5-fpm с разграничением по юзерам даёт гораздо большую защищённость, а заодно и возможность гибкой конфигурации каждого сайта. То есть, одному можно включить open_basedr, другому php-apc.
Если кому интересен более безопасный способ запуска php — вот моя старая заметка.
А вот это — скрипт для добавления нового сайта, с автогенерацией паролей и созданием БД.
Спасибо, кстати, за пост — помог в свое время разобраться.
Спасибо. Очень полезная информация.
Спасибо, прочитал. Я упаси боже не утверждаю, что описанного в моей статье достаточно для правильного развёртывания полноценного боевого сайта. Я просто хотел показать, как поставив стандартную LAMP'у безо всяких там nginx, chroot для апача и прочего, настроить её хотя бы с намёком на безопасность. Вообще говоря в www-data нет ничего столь уж катастрофичного, в отличие от неуказания той же open_basedir или разрешения system().
А если вы посмотрите на опрос, то вы увидите, что многие даже так не делают. Какой уж там nginx…
А если вы посмотрите на опрос, то вы увидите, что многие даже так не делают. Какой уж там nginx…
> Nginx + php5-fpm
Да хотя бы и апач с mpm_itk
Да хотя бы и апач с mpm_itk
А зачем снова, в очередной раз, обсуждать эту тему? Ведь эту статью точное также будут искать в гугле, если кому-то понадобится почитать данный материал. А в интернетах уж (как в русскоязычных, так и в англоязычных) тысячи подобных мануалов. У меня, собственно, только один вопрос — зачем, в очередной раз, разжевывать тему развёртывания сайта на linux-сервере? :)
>> Меня всегда интересовал вопрос — а нет ли где-нибудь на официальных ресурсах
php.net/functions
>> полного списка с описанием всех PHP функций, которые так или иначе могут дать доступ скрипту к компонентам и файлам системы.
_все_ функции так или иначе имеют доступ к файлам и компонентам системы
php.net/functions
>> полного списка с описанием всех PHP функций, которые так или иначе могут дать доступ скрипту к компонентам и файлам системы.
_все_ функции так или иначе имеют доступ к файлам и компонентам системы
>> в этой статье я хотел показать фатальную недостаточность данных манипуляций и мягко говоря некомпетентность тех, кто их тиражирует в интернете.
Не буду громко заявлять о компетентности, но вот логика некоторых решений как минимум вызывает сомнения. Тот же велосипед с темпом в папке сайта, избыточный для пользователя SFTP (да, для него он избыточен) и пр.
Если уж начали говорить о минимальной безопасности — где FastCGI или ITK? Где нормальное разграничение пользователей?
В общем, автор хоть и пошёл чуть-чуть дальше, но всё равно неизбежно повторил путь сотен предшественников. Сам по себе, конечно, молодец, но вот зачем очередная бессмысленная статья об этом на хабре?
Не буду громко заявлять о компетентности, но вот логика некоторых решений как минимум вызывает сомнения. Тот же велосипед с темпом в папке сайта, избыточный для пользователя SFTP (да, для него он избыточен) и пр.
Если уж начали говорить о минимальной безопасности — где FastCGI или ITK? Где нормальное разграничение пользователей?
В общем, автор хоть и пошёл чуть-чуть дальше, но всё равно неизбежно повторил путь сотен предшественников. Сам по себе, конечно, молодец, но вот зачем очередная бессмысленная статья об этом на хабре?
На опрос посмотрите — вот за этим. И нет, я мог бы написать очередную бессмысленную статью на тему nginx+php-fpm с БШ, мне же хотелось написть о стандартном LAMP безо всяких FastCGI и ITK. Потому что большинство ставит стандартный LAMP, использует стандартный LAMP и т.д. Тем, кто ставит itk, думается, никакие статьи не нужны.
Понимаете, таких статей — их очень много. Самый элементарный запрос в гугль: «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.
>> мне же хотелось написть о стандартном 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». Только хабра.
Да, очень оригинально.
См. мой ответ выше.
>> >> Если уж начали говорить о минимальной безопасности — где FastCGI или ITK? Где нормальное разграничение пользователей?
Где безопасность то? SFTP — это не безопасность. Это просто довольно экстравагантное решение в стандартной ситуации. SSH вообще на шареде давать нельзя.
Как к безопасности относится бессмысленно перемещённый темп, тоже не вполне понимаю. А всё остальное, в общем, «по канонам».
Где безопасность то? SFTP — это не безопасность. Это просто довольно экстравагантное решение в стандартной ситуации. SSH вообще на шареде давать нельзя.
Как к безопасности относится бессмысленно перемещённый темп, тоже не вполне понимаю. А всё остальное, в общем, «по канонам».
Хм, то есть FTP — это безопасность, а SFTP — уже нет. Интересная точка зрения. SFTP в любом случае безопасней FTP, а если вам так уж надо безопасности, что стандартных методов её обеспечения для SSH недостаточно, повесьте на сервере два демона SSH — один для пользователей хостинга, другой для админов. Ничего более безопасного я даже представить себе не могу. Пока что не слышал о фатальных уязвимостях в internal SFTP по ключу, позволяющих пользвоателю без ключа подключиться и получить какой-нибудь доступ к серверу. Хотя всё может быть…
temp перемещён не бессмысленно, а туда, где он уже есть у многих движков. Опять же — ничего суперкритичного в этом нет, спрятав temp вне корня сайта вы не закроете к нему доступ злоумышленников в случае взлома.
temp перемещён не бессмысленно, а туда, где он уже есть у многих движков. Опять же — ничего суперкритичного в этом нет, спрятав temp вне корня сайта вы не закроете к нему доступ злоумышленников в случае взлома.
Кто где говорил, что SFTP — это небезопасно? Просто довольно странная. Обычно для загрузки файлов пользователям хватает и обычного нешифрованного канала. Единственное интересное решение — ключи. Да, чтоб пароли не забывались. Но вы мне хоть одного среднего пользователя шареда покажите, который сможет сделать себе ключ и будет знать, как им пользоваться?
Плюс, SFTP поддерживают не все клиенты. В общем, я не говорю, что так менее безопасно. Как я выше уже написал — это просто экстравагантное решение.
>> temp перемещён не бессмысленно, а туда, где он уже есть у многих движков.
а у многих движков нет. Уж лучше какой-то стандартизации придерживаться и держать такие вещи в районе /tmp. А не городить очередной велосипед, за который админы, которым впоследствии, возможно, придётся это админить, будут костерить создателя по самое не балуйся.
Плюс, SFTP поддерживают не все клиенты. В общем, я не говорю, что так менее безопасно. Как я выше уже написал — это просто экстравагантное решение.
>> temp перемещён не бессмысленно, а туда, где он уже есть у многих движков.
а у многих движков нет. Уж лучше какой-то стандартизации придерживаться и держать такие вещи в районе /tmp. А не городить очередной велосипед, за который админы, которым впоследствии, возможно, придётся это админить, будут костерить создателя по самое не балуйся.
В районе /tmp — это очень странно. Если уж не в корне temp, то на уровень выше, но я всегда считал, что запихивать темп в системную помойку — это как раз нехорошо, не?
Помнится возникали какие-то проблемы с /tmp при использовании open_basediir
Да не, нет никаких проблем — прописываем /tmp в open_basedir и всё. Правда в этом лсучае все сайты получат доступ к сессиям соседей — но проблем работоспособности, по крайней мере, не будет.
Делаем нормальное разграничение правд для пользователей и всё нормально тут будет.
А зачем делать нормальное разграничение прав внутри директории, не предназначенной для разграничения прав? Не проще ли использовать всё же отдельные каталоги?
Что значит «не предназначенной для разграничения прав»? Это как? Там запрещено выставлять нормальных владельцев для разграничения доступа?
единственная особенность /tmp — это то, что он после перезагрузки сервера очищается. И там не принято давать возможность не исполнение, т.к. директория доступна всем подряд на запись.
Но это никак не значит, что там нельзя нормально разграничить права на файлы.
В общем, ваша фраза «мягко говоря некомпетентность тех, кто их тиражирует в интернете.» вызывает всё большую и большую улыбку.
единственная особенность /tmp — это то, что он после перезагрузки сервера очищается. И там не принято давать возможность не исполнение, т.к. директория доступна всем подряд на запись.
Но это никак не значит, что там нельзя нормально разграничить права на файлы.
В общем, ваша фраза «мягко говоря некомпетентность тех, кто их тиражирует в интернете.» вызывает всё большую и большую улыбку.
эм… «зачем делать нормальное разграничение».
Может быть для безопасности, о которой Вы пытались рассказать?
Может быть для безопасности, о которой Вы пытались рассказать?
>> повесьте на сервере два демона SSH — один для пользователей хостинга, другой для админов.
Может тогда уж для каждого пользователя отдельный SSH-демон заводить?:) Что уж капитальная секурность?:)
Может тогда уж для каждого пользователя отдельный SSH-демон заводить?:) Что уж капитальная секурность?:)
> стандартном 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 символов больше! Выпилить немедленно!
UFO just landed and posted this here
И к слову о phpmyadmin — это, безусловно, классная вещь, но почти всегда вместо него хватит adminer. Один файл, легкость и быстрота, уменьшение потенциальной опасности взлома через свою, пока, относительную малораспространенность. Активно развивается, несколько более удобных фич, по сравнению с pma.
Кроме этого в приведённых выше настройках не отключена функция eval. Увы, многим сайтам она зачем-то нужна, хотя всё же лучше её отключать.
Автор, я последовал совету, отключил eval, но почему то не работает.
Подскажи, почему? Как мне быть?)
Статья неплоха, но все же явно необходимо поставить apache2-mpm-itk и настроить пользователей. Плюс закрыть phpmyadmin при помощи .htaccess — т.к. дико дырявая штуковина.
Кстати, кто реально использует libapache2-mod-apparmor — оно хоть как-то помогает?
Кстати, кто реально использует libapache2-mod-apparmor — оно хоть как-то помогает?
Когда вы закончите уже OpenNet.ru копипастить?
Ну а апача то зачем? Я бы ещё понял, если какой-то mod_secirity использовался. Сейчас мейнстрим nginx с php-fpm на каждого юзверя свой процесс. Ну и всякие xcache в придачу.
Apparmor использую. По крайней мере он прикрывает и дыры в самом PHP.
Может весьма нубский вопрос, но на CentOS есть некий защитный механизм SELinux. Мне все лень его изучить и во время настройки веб-сервера было много с ним проблем, по этому пришлось отключить.
Вот мне собственно интересно, он влияет на защищенность самого веб-сервера или только оси?
Кстати, большое спасибо за статью и отдельное спасибо за комментарии в коде, очень познавательно.
Вот мне собственно интересно, он влияет на защищенность самого веб-сервера или только оси?
Кстати, большое спасибо за статью и отдельное спасибо за комментарии в коде, очень познавательно.
>> Для всех пользователей SFTP основной группой будет установлена www-data (дефолтная группа Apache2 в deb-based). Кроме этого, все создаваемые как пользователем по SFTP, так и Apache, файлы по умолчанию будут иметь права 0660, а каталоги — 0770. Поскольку у Apache и SFTP пользователя одна и та же группа, то по-умолчанию в любой новый файл или каталог сможет писать как пользователь, так и веб-сервер, вне зависимости от того, кто его создал. Что обычно и требуется.
Вот это странно, на мой взгляд.
Вот это странно, на мой взгляд.
Заранее прошу прощения за глупый вопрос. Я вот все это сделал, правда на убунте, а у меня – 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/"
Что я сделал не так? Буду очень благодарен.
так а в dirname вы никогда ничего и не создадите) Там надо создавать ещё один каталог, на который уже выставлять желаемые права.
Про ACL, кстати, никто и ничего так и не припомнил =)
Безопасность LAMP-стека? Расскажите нам про SELinux и AppArmor.
Забавно. Сначала не работала заливка по sftp. С шеллом /bin/false sftp не мог авторизоваться. Если оставить /bin/bash — авторизация проходит и можно заливать файлы. Но и войти через ssh нельзя, судя по всему, т.к. в конфиге sshd стоит «ForceCommand internal-sftp» для группы.
Интересно, почему в посте именно /bin/false, с которым sftp не работает?
Интересно, почему в посте именно /bin/false, с которым sftp не работает?
Sign up to leave a comment.
И снова о… LAMP и базово защищённый мини-хостинг своими руками