Это Канонический вопрос о защите стека LAMP
Каковы абсолютные рекомендации по обеспечению безопасности сервера LAMP?
Ответ Дэвида является хорошей основой для общих принципов усиления защиты серверов. Как указал Дэвид, это огромный вопрос. Конкретные методы, которые вы выберете, могут сильно зависеть от вашей среды и того, как будет использоваться ваш сервер. Предупреждение, это может потребовать много работы в тестовой среде, чтобы построить и сделать правильно. За этим следует много работы по интеграции в производственную среду и, что более важно, в бизнес-процесс.
Однако сначала проверьте, есть ли в вашей организации какие-либо политики повышения безопасности, так как они могут иметь самое непосредственное отношение. В противном случае, в зависимости от вашей роли, это может быть прекрасное время для их развития. Я бы также рекомендовал рассматривать каждый компонент отдельно снизу вверх.
L
Есть много хороших руководств, которые могут вам помочь. Этот список может вам помочь, а может и не помочь в зависимости от вашего дистрибутива.
А
Безопасность Apache может быть интересной. Мне легче укрепить ОС и поддерживать удобство использования, чем Apache или PHP.
М
P
Это наталкивается на саму идею безопасного программирования, которая представляет собой целую дисциплину. SANS и OWASP содержат невероятное количество информации по этому вопросу, поэтому я не буду пытаться воспроизводить ее здесь. Я сосредоточусь на настройке среды выполнения, а обо всем остальном позаботятся ваши разработчики. Иногда «P» в LAMP относится к Perl, но обычно к PHP. Я предполагаю последнее.
Вы задали вопрос, который, честно говоря, достоин нескольких книг по этой теме. Но есть несколько общих основных рекомендаций, которые хорошо работают:
Надеюсь, это поможет вам начать работу.
Вот хороший контрольный список, с которого мне нравится начинать.
Добавляя к тому, что предлагает Дэвид, чем более модульная ваша установка, я имею в виду ограничение доступа для определенных пользователей / групп, созданных специально для одной задачи, и ограничение их объема, тем более безопасным будет ваш стек LAMP: Примером этого является наличие пользователя Apache для файлов / папок Apache с соответствующими разрешениями, а не в каких-либо группах, которые могут получить доступ к важным системным файлам / папкам. Пользователь, который может получить доступ к таблицам MySql, связанным с вашими веб-сайтами, которые вы собираетесь обслуживать, и только к этим таблицам. Кроме того, вы можете ограничить их доступ, чтобы предоставить минимальный объем доступа из вызова PHP. Также убедитесь, что имя пользователя MySQL, используемое / предоставляемое через файл PHP, не совпадает с именем пользователя или паролем, используемым для другого пользователя.
Что это означает: если либо пользователь apache, либо пользователь MySql скомпрометированы, они не могут причинить никакого вреда за пределами папки (папок), к которой apache имеет доступ (в случае пользователя apache) и за пределами таблицы ( s) / database (s) (в случае пользователя базы данных MySQL).
Если каким-то образом пользователь MySQL будет скомпрометирован, он не сможет, например, получить доступ к базе данных и удалить все базы данных из MySQL и испортить все ваши данные. Они МОГУТ при некоторых обстоятельствах иметь возможность отбрасывать таблицы или вставлять информацию в некоторые таблицы в изолированной базе данных, поэтому важно предоставлять доступ к таблицам только там, где это абсолютно необходимо, и предоставлять только необходимые разрешения ... если вы этого не сделаете. t должны иметь привилегии отбрасывания таблиц или привилегии обновления, тогда не давайте их этому пользователю.
Кроме того, если по какой-то причине имя пользователя и пароль вашей административной учетной записи обнаружены для MySQL, если вы используете имя пользователя, отличное от любых имен пользователей в вашей системе, они должны сначала взломать безопасность вашей системы, прежде чем проникнуть в вашу базу данных, чтобы нанести ущерб. То же самое касается пользователя apache и доступа к файлам.
Пример время! Я собираюсь привести пример системы, чтобы упростить идею.
скажем, у вас есть пользователи в вашей системе (root должен быть отключен для безопасности с помощью чего-то вроде umod -l или passwd -l и т. д.): john, barney, terence и lisa.
вы можете создать пользователя в MySQL с именем bigbird (убедитесь, что вы используете хешированный пароль). Bigbird имеет только привилегии выбора и обновления, но не удаляет и не создает, и уж точно не . Кроме того, вы создаете другого административного пользователя MySQL с именем garfield для работы с базой данных MySQL и удаляете пользователя root из базы данных MySQL, чтобы его нельзя было скомпримировать. Гарфилд получил . привилегии во всем MySQL (фактически, это просто переименование root).
теперь вы создаете либо группу apache, либо пользователя, и мы назовем его apweb2. Appweb2 не является членом других групп, и все файлы / папки для apache хранятся в / home / apweb2 /. У каждого виртуального хоста будет своя собственная подпапка, и на каждом из этих хостов корень документа будет установлен в эту подпапку. Символьные ссылки будут отключены, чтобы случайно не предоставить доступ к остальной части системы.
Кроме того, вы можете ограничить доступ по ssh только определенным пользователям (или определенным группам, мне нравится помещать их в группу ssh и делать это единственное, что может использовать ssh).
Кроме того, вы можете выбрать, у каких пользователей есть привилегии sudo, чтобы еще больше ограничить работу. Еще один шаг, который вы можете сделать дальше, - это сделать всех пользователей ssh не способными к sudo, вы можете создать специальных пользователей, которые могут использовать sudo, которые не могут использовать ssh, так что после того, как вы войдете ssh, вам нужно будет войти в систему другого пользователя, чтобы иметь доступ к sudo.
Таким образом, модулируя каждый сегмент, если один будет скомпрометирован, весь стек не будет скомпрометирован, и вы сможете решить 1 проблему вместо того, чтобы начинать все заново с нуля.
Я нашел этот документ с SANS.org действительно полезным http://www.sans.org/score/checklists/linuxchecklist.pdf
В настоящее время не стоит пренебрегать виртуализацией контейнеров, а именно Docker, systemd-nspawn и механизмами виртуализации контейнеров, на которых они построены (пространства имен, cgroups). Использование виртуализации контейнеров позволяет изолировать процессы, например, если одна из служб будет скомпрометирована, злоумышленник не получит доступа к другим службам.
В случае с LAMP можно использовать, например, четыре контейнера Docker с SSH-сервером, Apache, MySQL, PHP-FPM / Python / Perl / и т. Д.