И снова о… LAMP и базово защищённый мини-хостинг своими руками

    Увидев в очередной раз презренный посыл в Google в ответ на вопрос о том, как развернуть собственную LAMP'у, решил написать данный пост. Чтобы хоть как-то разбавить тонны радостных отчётов об успешной установке из блогов, суть которых сводится к одной команде aptitude install blah-blah.

    Нет, ну конечно понятно, PHP самый надёжный язык, а все движки сайтов, на нём написанные, являются живым воплощением непробиваемой защиты от взлома. Тогда да — aptitude install apache2 — и будет вам счастье. Не забудьте оставить phpmyadmin по дефолтному адресу, да поставьте какое-нибудь дырявое FTP решето.

    Вообще, как оказалось, многие даже не в курсе, что взломав сайт и получив возможность исполнять свой PHP код, злоумышленник на системе с дефотными настройками сможет как минимум прочитать в вашей системе почти что угодно. Оно и понятно — работая с Linux привыкаешь как-то, что по дефолту безопасность находится на вполне достаточном уровне. А тут такая дыра…

    В общем — в этой статье в очередной раз описывается банальщина на тему как развернуть LAMP и дать доступ внешним пользователям к файлам и базам ваших сайтов. Т.е. как быстро сделать мини-хостинг своими руками. Однако, в отличие от, хостинг у нас будет хотя бы базово защищённым.

    Те, кому тема веб-серверов надоела, возможно смогут найти в статье интересные приёмы многопользовательского ограниченного доступа к серверу по SFTP.

    И нет, это не ещё одна статья с описанием установки Linux и выполнением aptitude install apache2. Скорее наоборот: в этой статье я хотел показать фатальную недостаточность данных манипуляций и мягко говоря некомпетентность тех, кто их тиражирует в интернете.

    Установка


    Всё будет описано на примере Debian.

    Для начала нужно установить всё необходимое (кстати, для Ubuntu phpMyAdmin лучше ставить из PPA):

    aptitude install apache2 mysql-server libapache2-mod-php5 ssh
    aptitude install phpmyadmin
    

    При установке phpMyAdmin генерируем произвольный пароль для подключения к БД, в остальном всё очевидно.

    Как это будет работать


    Все пользователи, которым нужно получить доступ к файлам на сервере, будут иметь локальную учётную запись с возможностью захода только по SFTP и только в папку с принадлежащими им сайтами. При этом будет поддерживаться авторизация как по паролю, так и по ключу. Интерактивный же вход по SSH будет невозможен, хотя если очень надо — его можно будет включить, причём тоже с закрытым доступом к системным файлам.

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

    Каждый сайт будет принадлежать некоему 'аккаунту', т.е. под одним 'аккаунтом' может быть несколько сайтов. К этим 'аккаунтам' привязываются SFTP пользователи, причём никто не мешает к одному 'аккаунту' привязать несколько пользователей. Дальше, внутри 'аккаунта', всё можно будет разрулить стандартными механизмами прав доступа в Linux.

    Пользователи и пароли от БД никак не будут зависеть от системных пользователей, управление БД будет происходить через стандартный phpMyAdmin.

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

    Немного подробней про структуру


    Все сайты будут лежать в каталогах вида /var/www/ACCOUNT/sites/SITENAME. ACCOUNT тут не обязательно означает какого-то системного пользователя, просто некий произвольный идентификатор.

    У системных пользователей, которые будут подключаться по SFTP для редактирования сайтов, в качестве домашней директории будет установлено /var/www/ACCOUNT/home/USERNAME. Соответственно в зависимости от значения ACCOUNT тот или иной пользователь будет иметь доступ к тому или иному аккаунту. Создание каталога home внутри аккаунта нужно для того, чтобы иметь возможность авторизовывать SFTP пользователей по ключам.

    Для всех пользователей SFTP основной группой будет установлена www-data (дефолтная группа Apache2 в deb-based). Кроме этого, все создаваемые как пользователем по SFTP, так и Apache, файлы по умолчанию будут иметь права 0660, а каталоги — 0770. Поскольку у Apache и SFTP пользователя одна и та же группа, то по-умолчанию в любой новый файл или каталог сможет писать как пользователь, так и веб-сервер, вне зависимости от того, кто его создал. Что обычно и требуется.

    Базы же будут использовать свой, полностью отдельный механизм авторизации и контроля доступа. Тут всё крайне просто: создаём пользователей и даём им права только на конкретные базы. Поэтому к этому вопросу возвращаться больше не будем.

    Создание 'аккаунтов' и системных пользователей


    Размещение сайта на сервере стоит начать с подготовки места под него и создания пользователя для работы с ним. Как описано выше, для сайта нам нужна папка вида /var/www/ACCOUNT/. В качестве ACCOUNT задействуем для примера 42. Просто 42. Ок, создаём папку:

    mkdir /var/www/42
    

    Кроме этого внутри аккаунта нам нужны каталоги home/USERNAME и sites. Создаём их:

    mkdir -p /var/www/42/home/marvin
    mkdir /var/www/42/sites
    

    Для будущей настройки SFTP сразу стоит убедиться, что и /var/www/42/sites, и все нижестоящие папки принадлежат root:root и ни у кого, кроме root, нет прав на запись в них.

    Дальше создаём пользователя. Чтобы не путаться с обычными, полноценными пользователями сервера, SFTP пользователей можно перенести в диапазон UID от 901 до 999. Если вам это не надо — уберите соотв. параметры. Если вы хотите авторизовываться только по ключу, то добавьте параметр --disabled-password. В итоге команда такая:

    adduser --home /var/www/42/home/marvin --no-create-home --shell /bin/false --firstuid 901 --lastuid 999 --ingroup www-data marvin
    

    Установка шелла в /bin/false гарантирует нам, что пользователь никак не сможет интерактивно зайти в систему.

    Настройка SFTP


    Настройка SFTP будет заключаться в том, что для всех членов группы www-data мы сделаем так, чтобы при заходе по SFTP они попадали сразу в папку sites 'аккаунта', в котором находится их HOME директория, без возможности выбраться выше по дереву каталогов.

    Делается это просто. Достаточно в конец файла /etc/ssh/sshd_config дописать код

    # Специальный доступ для пользователей из www-data: chroot в их HOME,
    # установленный umask 007, соответствующий 0660 для файлов и 0770 для каталогов
    Match Group www-data
            AllowTCPForwarding no
            X11Forwarding no
            ChrootDirectory %h/../../sites
            ForceCommand internal-sftp -u 0007
    

    И ткнуть sshd для обновления конфигурации:

    service ssh reload
    

    Этот кусочек кода для всех пользователей из группы www-data, во-первых, отключает TCP и X11 форвадинг (им незачем иметь доступ в вашу локалку). Во-вторых делает для них при заходе chroot в sites папку их 'аккаунта' (именно для этого нам нужно было делать sites папки доступными для записи только для root — иначе не работает chroot). Ну и в третьих меняет им обработчик SFTP на встроенный (которому не нужно полноценное окружение с шеллом и прочим), попутно говоря ему создавать все файлы и папки со значение umask в 007. То есть права по умолчанию на новые файлы будут 0660, а на каталоги — 0770.

    Настройка Apache и phpMyAdmin


    Как-либо специфично настраивать Apache для обеспечения базовой работы не нужно. Единственное, что в Debian пакет PHP5 идёт с интегрированным патчем Suhosin, повышающим безопасность. Он будет необходим при настройке конфигов сайта, хотя вполне можно обойтись и без него.

    А так в целом для Apache нужно лишь изменить umask для создаваемых файлов и папок на такой же, который мы использовали для настройки SFTP. Делается это путём добавления в /etc/apache2/envvars строчек:

    # umask 007 для создания файлов с разрешениями 0660 и каталогов с 0770
    umask 007
    

    Для минимальной настройки phpMyAdmin нужно лишь поменять адрес, по которому он будет доступен, с неприлично бестолкового your.site/phpmyadmin на что-то другое. Для этого в файле /etc/phpmyadmin/apache.conf нужно заменить строчку

    Alias /phpmyadmin /usr/share/phpmyadmin
    

    на, например:

    # А мы немного схитрим!
    Alias /вдушу_влазер /usr/share/phpmyadmin
    

    Не забывайте перезапускать Apache:

    service apache2 restart
    

    Добавление сайтов


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

    Для размещения файлов нужно из-под root создать каталог сайта в папке нужного 'аккаунта'. Например:

    mkdir /var/www/42/sites/deep-thought.net
    

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

    chown marvin:www-data /var/www/42/sites/deep-thought.net
    chmod 0750 /var/www/42/sites/deep-thought.net
    

    Ок, теперь пользователь может зайти и залить файлы сайта. Осталось настроить апач. Для этого, как всегда, создаём файл настроек в директории /etc/apache2/sites-available. Содержимое этого файла для сайта deep-thought.net с данными в каталоге /var/www/42/sites/deep-thought.net должно быть примерно таким:

    <VirtualHost *:80>
            ServerAdmin webmaster@deep-thought.net
            ServerName deep-thought.net
    
            # Корневая директория сайта
            DocumentRoot /var/www/42/sites/deep-thought.net
    
            <Directory /var/www/42/sites/deep-thought.net>
                    # Тут всякая стандартная хрень по типу
                    #Options FollowSymLinks
                    #AllowOverride All
                    
                    <IfModule mod_php5.c>
                            # Запрещаем php вылазить куда ему совершенно не надо
                            php_admin_value open_basedir /var/www/42/sites/deep-thought.net
                            # Поскольку вылазить запретили - сохраняем временные файлы и сессии внутри корня сайта
                            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
                            # Отключаем возможность инклуда по URL
                            php_admin_flag allow_url_include off
                            # Отключаем возможность динамической подгрузки модулей PHP
                            php_admin_flag enable_dl off
                            # Отключаем всю лабудень для системных вызовов
                            php_admin_value suhosin.executor.func.blacklist apache_note,apache_setenv,closelog,debugger_off,debugger_on,define_syslog_variables,escapeshellarg,escapeshellcmd,ini_restore,openlog,passthru,pclose,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec,syslog,system,url_exec
                    </IfModule>
            </Directory>
    
            # Закрываем, на всякий случай, доступ в temp
            <Directory /var/www/42/sites/deep-thought.net/temp>
                    AllowOverride None
                    Order Deny,Allow
                    Deny from All
            </Directory>
    
            ErrorLog /var/log/apache2/error.log
    
            # Possible values include: debug, info, notice, warn, error, crit,
            # alert, emerg.
            LogLevel warn
    
            CustomLog /var/log/apache2/access.log combined
    
    </VirtualHost>
    

    Важным тут является только содержимое блока <IfModule mod_php5.c>. В нём находятся настройки PHP, которые во-первых, запрещают обращение к файлам вне корневой директории сайта (open_basedir и перенос в temp), во-вторых отключают две крайне опасные возможности PHP (allow_url_include, enable_dl), которые всё ещё присутствую в современных версиях PHP и даже могут быть включены. И наконец в-третьих, запрещают PHP скриптам использовать целый ряд функций взаимодействия с ОС. Например, функций исполнения произвольной команды. Список функций честно выцеплен откуда-то из интернета и не претендует на всеобщий охват, хотя вроде бы является достаточным для обеспечения безопасности.

    Немного про temp: поскольку мы запрещаем PHP обращаться к файлам вне корневой директории сайта, то нам нужно указать каталог для сохранения временных файлов (файлов, загружаемых пользователями сайта на сервер через стандартный механизм загрузки из HTML формы) и файлов сессий внутри корня сайта. Каталог этот нужно, естественно, предварительно создать. Кроме этого лучше бы явно закрыть к нему доступ из интернета, что и сделано во втором блоке Directory. Иначе кто-нибудь может невзначай получить сессии ваших пользователей.

    Если на сервере не установлен Suhosin, то вместо suhosin.executor.func.blacklist можно использовать стандартную опцию PHP disable_functions. Правда её нужно указывать в php.ini, т.е. она будет действовать на все сайты на вашем сервере.

    Кроме этого в приведённых выше настройках не отключена функция eval. Увы, многим сайтам она зачем-то нужна, хотя всё же лучше её отключать. Обратите внимание на опции suhosin.executor.disable_eval и suhosin.executor.disable_emodifier всё того же Suhosin.

    После того, как вы подготовите нужный вам конфиг, просто активируйте сайт:

    a2ensite deep-thought.net
    

    И не забудьте пнуть апач:

    service apache2 reload
    

    Ну и конечно нужно залить файлы и базу данных сайта на сервер — без них вряд ли что-то заработает.

    Тюнинг SSH: ключи и интерактивный вход


    Для доступа пользователей SFTP по ключам нужно сделать всё тоже, что делается всегда: внутри HOME каталога создать директорию .ssh/, в ней файлик authorized_keys, в который прописать публичный ключи для пользователя.

    Кроме этого, можно некоторым пользователям открыть интерактивный доступ на сервер. Для этого нужно, во-первых, подготовить в корневой папке соответствующего 'аккаунта' нужное chroot окружение, как минимум с интерпретатором и всеми необходимыми виртуальными ФС. Делается это стандартно и ничего сложно в этом нет.

    Дальше можно создать дополнительную группу для интерактивного входа. Например, ssh-interactive:

    addgroup --gid 900 ssh-interactive
    

    Добавить в неё нужных пользователей, попутно сменив им SHELL на полноценный bash:

    usermod -a -G ssh-interactive --shell /bin/bash marvin
    

    И прописать для этой группы специфические настройки в sshd_config. Для этого нужно модифицировать директиву Match, относящейся к www-data, дописав к ней !ssh-interactive, дабы она не распространялась на пользователей этой группы:

    Match Group www-data,!ssh-interactive
    

    И после неё добавить ещё одну директиву Match:

    # Интерактивный вход по SSH для доступа к коду сайтов
    Match Group www-data,ssh-interactive
            AllowTCPForwarding no
            X11Forwarding no
            ChrootDirectory %h/../../
    

    Проблема только в том, что для членов группы ssh-interactive umask больше не будет выставляться в 007. Исправить это можно дописав соответствующий параметр в глобальных настройках подсистемы sftp в sshd_config. Кстати, вряд ли вы захотите перетаскивать компоненты openssh в chroot окружение, так что можно заодно сменить внешний обработчик sftp на внутреннюю реализацию:

    Subsystem sftp internal-sftp -u 0007
    

    Подробней про конфигурацию SFTP: http://en.wikibooks.org/wiki/OpenSSH/Cookbook/SFTP

    В заключение


    Меня всегда интересовал вопрос — а нет ли где-нибудь на официальных ресурсах полного списка с описанием всех PHP функций, которые так или иначе могут дать доступ скрипту к компонентам и файлам системы. Приведённый выше список честно взят из интернета, так что если кто поделится ссылочкой на списочек функций — буду премного благодарен.

    Ну и да — если есть какие-то комментарии по поводу того, что ещё минимально можно сделать для обеспечения безопасной работы простейшего хостинга — пишите.
    А вы ограничиваете PHP хотя бы с помощью open_basedir?

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

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 76
    • +3
      Проще найти нормального(!) один раз админа, т.к. все равно какие-то вещи можно упустить. К тому же apache, лучше бы была связка LNPP :)
      • +3
        Во-первых, найти нормального админа — это архи сложная задача. Особенно если админ вам нужен ровно на час — поднять веб-сервер с вашим сайтом. Что-то мне подсказывает, что большинство админов сделают aptitude install apache2.

        Во-вторых — разворачивание LAMP — это некий стандартный процесс знакомства с администрированием. Все хотят развернуть LAMP и все гордятся, когда у них это получается. Пускай хоть не оставляют своим LAMP'ом дырень у себя в сервере, раз уж разворачивают. Да и заодно пускай призадумаются о безопасности.
        • 0
          Как развернувший такую LAMPу заинтересовано прочитал статью.
          Но у меня несколько другая платформа. FreeBSD
          Надо будет за чашкой кофе не на боевой системе (клоне/резерве) проверить ваши выкладки.
        • +1
          Иногда требуется поддержка .htaccess(например на shared хостинге).
          Тут уже получится nginx+apache как минимум.
          • +1
            В эпоху chef и puppet мусолить тему о том, как тысячным способом поднять самый популярный в мире стек веб-технологий, как-то не комильфо)
            • 0
              Не в тему, по-моему… Разница лишь в том как конфигурацию описывать «декларативно» или «императивно». Содержание конфигов и набор пакетов всё равно нужно будет формировать.
          • +2
            Опять?! Сколько еще админов тут не отписалось об сверхсложном apt-get?
            • –2
              Где apt-get, какой apt-get? Вы бы хоть вступление прочитали, что ли. Эта статья, вообще-то, написана как раз под впечатлением от засилья админов, отписывающихся о сверхсложном apt-get. Или может вы тоже считаете, что достаточно просто написать apt-get и веб-сервер готов?
              • +5
                Ага, тут у нас не apt-get, а aptitude. Да, не FTP, а SFTP. Но суть то не меняется. «Смотрите, я смог LAMPу!». Молодец автор. Но нам то это зачем?
                • НЛО прилетело и опубликовало эту надпись здесь
            • НЛО прилетело и опубликовало эту надпись здесь
              • +1
                Поскольку мне как раз это будет нужно, может быть вы поделитесь как это делать?
                • 0
                  Ставить не apache2, а apache2-mpm-itk. См. гугель, как с этим дальше работать.
                • –1
                  С itk меня всегда интересовал один вопрос: если запускать php от имени пользвоателя, которому принадлежит сайт, то php будет иметь права на запись во все файлы сайта. Что хреновенько. Если запускать от имени www-data, но с группой пользователя — тогда непонятно, зачем использовать itk. Получается, что для каждого сайта нужно создавать два пользователя — один для входа по (S)FTP, другой для апача, ну и одну группу. Я так и делал, когда использвоал itk. Но может я чего-то не догоняю?
                  • 0
                    С itk меня всегда интересовал один вопрос: если запускать php от имени пользвоателя, которому принадлежит сайт, то php будет иметь права на запись во все файлы сайта. Что хреновенько.
                    С точки зрения модели безопасности — всё нормально. Да, сайт пользователя могут поломать, зато другие пользователи гарантированно не пострадают. Кстати говоря, битовую маску доступа можно и через ftp/sftp менять. Только вряд ли кто-нибудь из пользователей «шареда» будет заморачиваться.

                    Получается, что для каждого сайта нужно создавать два пользователя
                    Можно и одним пользователем обойтись. Сконфигурять mpm_itk для сайта так:
                    AssignUserId www-data usergroup
                    При этом EUID www-data доступа к файлам пользователя не дает вообще никакого. Поэтому можно разрешать/запрещать доступ исключительно правами группы. Только 99% пользователей этим заниматься не будет, даже если подробную инструкцию написать.
                    • 0
                      Меня всегда интересовал вопрос — а нет ли где-нибудь на официальных ресурсах полного списка с описанием всех PHP функций, которые так или иначе могут дать доступ скрипту к компонентам и файлам системы.
                      Нет такого списка. Искал я как-то список функций, которые могут выполнить внешнюю программу, так даже и этого не нашлось. Есть вот такой перечень, и он не полный — там не хватает, как минимум, popen и pcntl_exec. А в твоем списке отсутствует самый обычный exec.
                    • –1
                      И, если задумать, есть ещё один вопрос: а вам не страшно запускать апач с полными root привилегиями, которые необходимы для работы itk? Что-то я начинаю сомневаться, что давая полного рута веб-серверу вы делаете его безопасней. Обход open_basedir и disable_functions не так страшен, как рут, разве нет? Вроде как itk не рекомендуют ставить на продакшен как раз потому, что он потенциально небезопасен. Хотя я хз, никогда плотно с itk не работал и в вопросе досконально не разбирался.
                      • +1
                        Апач в любом случае запускается с привилегиями root, и потом их дропает. Без root невозможно забиндить привилегированный 80-й порт.
                    • 0
                      Мне тут ссылочку кинули на этот пост, нас всех интересует один вопрос:
                      чем руководствовался ТС, когда прописывал временную директорию в веб-директории:
                      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, где лежат сессии не самая лучшая идея, особенно если листинг каталогов включен.

                        • +5
                          Я вообще то писал это к тому, что размещать tmp в веб директории — это далеко не здравая идея.
                          А то, что открывать доступ к tmp у меня и в мыслях не было.
                          • +1
                            Это да. Видимо лень создавать каталог /var/www/ACCOUNT/sites/SITENAME/www для docroot — других объяснений не вижу.
                            • +1
                              А самое веселье будет когда начнутся бекапы через месяц-два:) Особенно если очистку сессий в этом самом дебиане не включить:)
                            • +3
                              А зачем вообще временную директорию класть в директорию сайта?

                              Не лучше ли её вынести на уровень выше?
                              • –1
                                Я сам сайт опускаю на уровень ниже.
                            • –1
                              Да ничем, если честно. Только тем, что пускай все файлы сайта лежат в одном месте, всё равно доступа туда нету. Тем паче что многие движки уже имеют эту temp (или tmp), ровно так же зарезанную с помощью .htaccess. Зачем сущности плодить?
                            • +4
                              Использую похожую схему, только с nginx и php-fpm. Отличия:

                              — корень сайта ставлю как /var/www/username/example.com/{web,www,htdocs} — у многих фреймворков по дефолту в корне сайта лежат только файлы, к которым необходим доступ из веба (index.php и статика), а код фреймворка и приложения из веба недоступен и нет необходимости закрывать доступ к ним, tmp и прочим каталогам (например .git), более того как php обрабатывается только index.php, и даже если получится залить php файл на сайт, то выполнится он не сможет.

                              — nginx и php работают с правами пользователя аккаунта

                              — шелл по умолчанию есть у всех, деплой и обновления обычно через git идут
                              • 0
                                Также логи сайта храню в /var/www/username/example.com/log — удобно, в /var/log/ только общесистемные вещи.
                              • +16
                                Запуск всех сайтов от одного юзера www-data это очень плохой совет. Автор, как это часто бывает, пишет о себе
                                в этой статье я хотел показать фатальную недостаточность данных манипуляций и мягко говоря некомпетентность тех, кто их тиражирует в интернете.

                                Связка Nginx + php5-fpm с разграничением по юзерам даёт гораздо большую защищённость, а заодно и возможность гибкой конфигурации каждого сайта. То есть, одному можно включить open_basedr, другому php-apc.

                                Если кому интересен более безопасный способ запуска php — вот моя старая заметка.

                                А вот это — скрипт для добавления нового сайта, с автогенерацией паролей и созданием БД.
                                • +1
                                  Спасибо, кстати, за пост — помог в свое время разобраться.
                                  • 0
                                    Спасибо. Очень полезная информация.
                                    • –2
                                      Спасибо, прочитал. Я упаси боже не утверждаю, что описанного в моей статье достаточно для правильного развёртывания полноценного боевого сайта. Я просто хотел показать, как поставив стандартную LAMP'у безо всяких там nginx, chroot для апача и прочего, настроить её хотя бы с намёком на безопасность. Вообще говоря в www-data нет ничего столь уж катастрофичного, в отличие от неуказания той же open_basedir или разрешения system().

                                      А если вы посмотрите на опрос, то вы увидите, что многие даже так не делают. Какой уж там nginx…
                                      • 0
                                        > Nginx + php5-fpm

                                        Да хотя бы и апач с mpm_itk
                                      • +1
                                        А зачем снова, в очередной раз, обсуждать эту тему? Ведь эту статью точное также будут искать в гугле, если кому-то понадобится почитать данный материал. А в интернетах уж (как в русскоязычных, так и в англоязычных) тысячи подобных мануалов. У меня, собственно, только один вопрос — зачем, в очередной раз, разжевывать тему развёртывания сайта на linux-сервере? :)
                                        • 0
                                          Тут всё же не сайт разворачивается, и даже не куча сайтов, а куча групп сайтов.
                                        • 0
                                          >> Меня всегда интересовал вопрос — а нет ли где-нибудь на официальных ресурсах
                                          php.net/functions

                                          >> полного списка с описанием всех PHP функций, которые так или иначе могут дать доступ скрипту к компонентам и файлам системы.

                                          _все_ функции так или иначе имеют доступ к файлам и компонентам системы
                                          • +4
                                            >> в этой статье я хотел показать фатальную недостаточность данных манипуляций и мягко говоря некомпетентность тех, кто их тиражирует в интернете.
                                            Не буду громко заявлять о компетентности, но вот логика некоторых решений как минимум вызывает сомнения. Тот же велосипед с темпом в папке сайта, избыточный для пользователя SFTP (да, для него он избыточен) и пр.

                                            Если уж начали говорить о минимальной безопасности — где FastCGI или ITK? Где нормальное разграничение пользователей?

                                            В общем, автор хоть и пошёл чуть-чуть дальше, но всё равно неизбежно повторил путь сотен предшественников. Сам по себе, конечно, молодец, но вот зачем очередная бессмысленная статья об этом на хабре?
                                            • –2
                                              На опрос посмотрите — вот за этим. И нет, я мог бы написать очередную бессмысленную статью на тему nginx+php-fpm с БШ, мне же хотелось написть о стандартном LAMP безо всяких FastCGI и ITK. Потому что большинство ставит стандартный LAMP, использует стандартный LAMP и т.д. Тем, кто ставит itk, думается, никакие статьи не нужны.
                                              • 0
                                                Понимаете, таких статей — их очень много. Самый элементарный запрос в гугль: «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.
                                                • –2
                                                  Вот так вот, по приведённой вами статье, все и ставят. А потом удивляются. Да, таких статей очень много, равно как и очень много взломанных сайтов. Посмотрите на голосование в конце статьи — думаю, всё поймёте.
                                                • 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». Только хабра.

                                                  Да, очень оригинально.
                                                  • –1
                                                    См. мой ответ выше.
                                                    • 0
                                                      >> >> Если уж начали говорить о минимальной безопасности — где FastCGI или ITK? Где нормальное разграничение пользователей?

                                                      Где безопасность то? SFTP — это не безопасность. Это просто довольно экстравагантное решение в стандартной ситуации. SSH вообще на шареде давать нельзя.

                                                      Как к безопасности относится бессмысленно перемещённый темп, тоже не вполне понимаю. А всё остальное, в общем, «по канонам».
                                                      • 0
                                                        Хм, то есть FTP — это безопасность, а SFTP — уже нет. Интересная точка зрения. SFTP в любом случае безопасней FTP, а если вам так уж надо безопасности, что стандартных методов её обеспечения для SSH недостаточно, повесьте на сервере два демона SSH — один для пользователей хостинга, другой для админов. Ничего более безопасного я даже представить себе не могу. Пока что не слышал о фатальных уязвимостях в internal SFTP по ключу, позволяющих пользвоателю без ключа подключиться и получить какой-нибудь доступ к серверу. Хотя всё может быть…

                                                        temp перемещён не бессмысленно, а туда, где он уже есть у многих движков. Опять же — ничего суперкритичного в этом нет, спрятав temp вне корня сайта вы не закроете к нему доступ злоумышленников в случае взлома.
                                                        • 0
                                                          Кто где говорил, что SFTP — это небезопасно? Просто довольно странная. Обычно для загрузки файлов пользователям хватает и обычного нешифрованного канала. Единственное интересное решение — ключи. Да, чтоб пароли не забывались. Но вы мне хоть одного среднего пользователя шареда покажите, который сможет сделать себе ключ и будет знать, как им пользоваться?

                                                          Плюс, SFTP поддерживают не все клиенты. В общем, я не говорю, что так менее безопасно. Как я выше уже написал — это просто экстравагантное решение.

                                                          >> temp перемещён не бессмысленно, а туда, где он уже есть у многих движков.
                                                          а у многих движков нет. Уж лучше какой-то стандартизации придерживаться и держать такие вещи в районе /tmp. А не городить очередной велосипед, за который админы, которым впоследствии, возможно, придётся это админить, будут костерить создателя по самое не балуйся.
                                                          • –1
                                                            В районе /tmp — это очень странно. Если уж не в корне temp, то на уровень выше, но я всегда считал, что запихивать темп в системную помойку — это как раз нехорошо, не?
                                                            • 0
                                                              Помнится возникали какие-то проблемы с /tmp при использовании open_basediir
                                                              • –1
                                                                Да не, нет никаких проблем — прописываем /tmp в open_basedir и всё. Правда в этом лсучае все сайты получат доступ к сессиям соседей — но проблем работоспособности, по крайней мере, не будет.
                                                                • 0
                                                                  Делаем нормальное разграничение правд для пользователей и всё нормально тут будет.
                                                                  • –2
                                                                    А зачем делать нормальное разграничение прав внутри директории, не предназначенной для разграничения прав? Не проще ли использовать всё же отдельные каталоги?
                                                                    • +1
                                                                      Что значит «не предназначенной для разграничения прав»? Это как? Там запрещено выставлять нормальных владельцев для разграничения доступа?

                                                                      единственная особенность /tmp — это то, что он после перезагрузки сервера очищается. И там не принято давать возможность не исполнение, т.к. директория доступна всем подряд на запись.

                                                                      Но это никак не значит, что там нельзя нормально разграничить права на файлы.

                                                                      В общем, ваша фраза «мягко говоря некомпетентность тех, кто их тиражирует в интернете.» вызывает всё большую и большую улыбку.
                                                                      • 0
                                                                        эм… «зачем делать нормальное разграничение».
                                                                        Может быть для безопасности, о которой Вы пытались рассказать?
                                                              • 0
                                                                >> повесьте на сервере два демона SSH — один для пользователей хостинга, другой для админов.

                                                                Может тогда уж для каждого пользователя отдельный SSH-демон заводить?:) Что уж капитальная секурность?:)
                                                        • 0
                                                          > стандартном LAMP безо всяких FastCGI и ITK

                                                          $ aptitude show apache2-mpm-itk/stable
                                                          Пакет: apache2-mpm-itk
                                                          Новый: да
                                                          Состояние: не установлен
                                                          Версия: 2.2.16-6+squeeze10
                                                          Приоритет: дополнительный
                                                          Раздел: net
                                                          … blablabla

                                                          В каком месте он нестандартный? Ах да, надо же при установке всего этого дела написать на целых 16 символов больше! Выпилить немедленно!
                                                      • –5
                                                        Самый простой вариант купить тот же ISPmanager за 30 евро, и не страдать фигней.
                                                        • 0
                                                          И к слову о phpmyadmin — это, безусловно, классная вещь, но почти всегда вместо него хватит adminer. Один файл, легкость и быстрота, уменьшение потенциальной опасности взлома через свою, пока, относительную малораспространенность. Активно развивается, несколько более удобных фич, по сравнению с pma.
                                                          • 0
                                                            Кроме этого в приведённых выше настройках не отключена функция eval. Увы, многим сайтам она зачем-то нужна, хотя всё же лучше её отключать.


                                                            Автор, я последовал совету, отключил eval, но почему то не работает.

                                                            Подскажи, почему? Как мне быть?)
                                                            image
                                                            • 0
                                                              eval таким образом можно отключить только через Suhosin. disable_functions на него не расспространяется.
                                                              • +1
                                                                disable_functions отключает функции, а eval не функция, а языковая конструкция. Матчасть-то нужно было подучить ;).
                                                                • 0
                                                                  Спасибо, капитан)
                                                                  Я даже смайлик поставил в конце предыдущего сообщения.
                                                              • 0
                                                                Статья неплоха, но все же явно необходимо поставить apache2-mpm-itk и настроить пользователей. Плюс закрыть phpmyadmin при помощи .htaccess — т.к. дико дырявая штуковина.

                                                                Кстати, кто реально использует libapache2-mod-apparmor — оно хоть как-то помогает?
                                                                • +9
                                                                  Когда вы закончите уже OpenNet.ru копипастить?
                                                                  • +3
                                                                    Ну а апача то зачем? Я бы ещё понял, если какой-то mod_secirity использовался. Сейчас мейнстрим nginx с php-fpm на каждого юзверя свой процесс. Ну и всякие xcache в придачу.
                                                                    • 0
                                                                      Apparmor использую. По крайней мере он прикрывает и дыры в самом PHP.
                                                                      • 0
                                                                        Может весьма нубский вопрос, но на CentOS есть некий защитный механизм SELinux. Мне все лень его изучить и во время настройки веб-сервера было много с ним проблем, по этому пришлось отключить.

                                                                        Вот мне собственно интересно, он влияет на защищенность самого веб-сервера или только оси?

                                                                        Кстати, большое спасибо за статью и отдельное спасибо за комментарии в коде, очень познавательно.
                                                                        • 0
                                                                          Если тонкими настройками пренебрегать, то защищает штатным образом установленные файлы, включая файлы сервера (апача).
                                                                        • 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/"
                                                                            Что я сделал не так? Буду очень благодарен.
                                                                            • 0
                                                                              dir_name должна принадлежать root:root и иметь права, скажем, 0755.
                                                                              • 0
                                                                                ставлю права 755 – пускает, но при попытке что-нибудь создать – Insufficient access privileges for item
                                                                          • 0
                                                                            так а в dirname вы никогда ничего и не создадите) Там надо создавать ещё один каталог, на который уже выставлять желаемые права.
                                                                            • 0
                                                                              Ну я пытался в dirname/sites
                                                                              Все, понял, спасибо огромное.
                                                                            • 0
                                                                              Про ACL, кстати, никто и ничего так и не припомнил =)
                                                                              • 0
                                                                                Безопасность LAMP-стека? Расскажите нам про SELinux и AppArmor.
                                                                                • 0
                                                                                  Забавно. Сначала не работала заливка по sftp. С шеллом /bin/false sftp не мог авторизоваться. Если оставить /bin/bash — авторизация проходит и можно заливать файлы. Но и войти через ssh нельзя, судя по всему, т.к. в конфиге sshd стоит «ForceCommand internal-sftp» для группы.
                                                                                  Интересно, почему в посте именно /bin/false, с которым sftp не работает?

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