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

Однако сначала проверьте, есть ли в вашей организации какие-либо политики ужесточения, поскольку они могут быть наиболее актуальными. Если нет, в зависимости от вашей роли, это может быть отличное время для их создания. Я также рекомендовал бы заниматься каждым компонентом отдельно снизу вверх.

L
Есть много хороших гидов, которые могут вам помочь. Этот список может или не может помочь вам в зависимости от вашего распространения.

• Центр Тестов Интернет-Безопасности - Распространение, определенное для главных ароматов
• CentOS Hardening HowTo - внимательно следит за руководством по CIS RHEL5, но его гораздо легче прочитать
• NIST SP800-123 - Руководство по общей безопасности сервера
• NSA Hardening Factsets - Не так недавно, как в СНГ, но все еще в основном применимо
• Tiger - Live Security Security Audit Программное обеспечение

А
Апач может быть весело, чтобы обеспечить. Мне легче укрепить ОС и поддерживать удобство использования, чем Apache или PHP.

• Apache Server Hardening - этот вопрос на дочернем сайте IT Security содержит много полезной информации.
• Центр тестов безопасности в Интернете - Опять же, тесты Apache.
• Советы по безопасности Apache - прямо из проекта Apache, похоже, он охватывает основы
• DISA Hardening Checklist - Контрольный список от ребят из DoD Information Assurance

М

• Центр тестов безопасности в Интернете - опять же, но для тестов MySQL
• OWASP MySQL Hardening
• Общие правила безопасности - базовый контрольный список от разработчиков проекта

P
Это сводит на нет всю идею безопасных практик программирования, которая представляет собой целую дисциплину. SANS и OWASP располагают смехотворным количеством информации по этому вопросу, поэтому я не буду пытаться копировать ее здесь. Я сосредоточусь на конфигурации времени выполнения и позволю вашим разработчикам беспокоиться об остальном. Иногда буква "P" в LAMP относится к Perl, но обычно к PHP. Я предполагаю последнее.

• Укрепление PHP - Небольшое обсуждение, также на сайте IT Security SE.
• Hardened PHP Project - основной проект, который производит Suhosin, попытку исправить приложение PHP, чтобы проект против определенных типов атак.
• Укрепление PHP с Suhosin - краткое руководство специально для Suhosin
• Укрепление PHP из php.ini - краткое, но неплохое обсуждение некоторых параметров времени выполнения, связанных с безопасностью

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

1. Держите в курсе. Это означает ОС, все сервисы и ОСОБЕННО все веб-приложения, которые вы используете.
2. Отключите все ненужные службы, ограничьте те, которые необходимы, минимальным воздействием (если вы не подключаетесь к MySQL удаленно, а не прослушиваете его по TCP), и запустите межсетевой экран на основе хоста. (Если это строго LAMP, у вас должно быть хорошо с 80 и 443, но, возможно, и с SSH для администрирования.))
3. Используйте надежные пароли. Еще лучше, если вы используете SSH, используйте только аутентификацию на основе ключей.
4. Убедитесь, что вы не вошли в систему как root. Войдите как пользователь и используйте su & sudo.
5. Хотя это не делает вещи более безопасными, вы должны запустить такие инструменты, как logwatch, чтобы вы знали, что происходит на вашем сервере.

Надеюсь, что это поможет вам начать.

Вот хороший контрольный список, с которого я хотел бы начать.

Брандмауэр

• Хороший подход состоит в том, чтобы не начинать трафик, а затем открывать только то, что вам нужно, так, как вам это нужно. Это приводит к открытию минимального количества портов / ips, чтобы все заработало, и это минимизирует вашу уязвимость.
• Для LAMP-сервера вам может потребоваться открыть порты только для http/https для всего мира и ssh для sysadmins.
• Убедитесь, что такие вещи, как трафик ipv6 заблокирован, если не используете его
• AWS предоставляет группы безопасности, у linux есть iptables, а также множество пакетов на выбор.

SSH & Пользователи

• Нет пароля для доступа по SSH (используйте закрытый ключ)
• Не разрешайте root для ssh (соответствующие пользователи должны войти в ssh, затем su или sudo)
• Используйте sudo для пользователей, чтобы команды регистрировались
• Записывайте несанкционированные попытки входа в систему (и подумайте, как программное обеспечение блокирует / блокирует пользователей, которые пытаются получить доступ к вашему серверу слишком много раз, например fail2ban)
• ssh на нестандартном порте (это может быть полезно, чтобы убедиться, что вы не слишком низко зависаете, и держите много раздражающего трафика подальше, но не сделаете много для безопасности, особенно для себя)
• заблокируйте ssh только для того диапазона IP-адресов, который вам требуется (большой диапазон лучше, чем отсутствие диапазона)

База данных

• Дезинфицировать пользовательские данные
• Параметризация запросов
• Рассмотрите возможность абстрагирования БД от ее собственной машины. Это разделение может затруднить доступ злоумышленника к вашему веб-стеку и наоборот.
• Как и любое программное обеспечение , актуальное важно.
• Пользователь для каждой цели. При создании пользователей начните без каких-либо привилегий и добавляйте только тех, которые им необходимы, чтобы предварительно сформировать свою роль. Наличие отдельных пользователей для разных приложений (или иногда отдельных частей приложений) поможет уменьшить выгоду, которую злоумышленник может получить, если они скомпрометируют какую-либо одну учетную запись. Также будьте осторожны со специальными привилегиями, такими как GRANT, которые не следует назначать легко.
• Наличие политики для периодической смены паролей - хорошая идея. Если вы беспокоитесь о количестве необходимых усилий, помните, что менее частое - это лучше, чем никогда.
• Понять шифрование пароля. Соляные пароли. Не используйте MD5!

Программного обеспечения

• Поддерживайте программное обеспечение в актуальном состоянии (ОС, веб-сервер, язык сценариев, CMS). Многие люди будут искать известные уязвимости в старых (не исправленных) версиях.
• Удалите все ненужное программное обеспечение (в идеале не храните пакет, необходимый для компиляции программного обеспечения на производственных серверах, лучше предварительно скомпилировать программное обеспечение и сделать его доступным в виде пакета для ваших производственных компьютеров)
• Убедитесь, что права доступа к файлам заблокированы (особенно для таких вещей, как пользовательские загрузки и файлы конфигурации)
• Защитите паролем область администратора для CMS на уровне веб-сервера (проверка подлинности http может находиться перед уязвимой CMS и помочь заблокировать доступ, что является хорошим способом предотвращения атак)
• Используйте SSL для области администратора и других конфиденциальных данных
• Автоматизируйте управление своими серверами и инфраструктурой (что-то вроде Puppet, Chef или SaltStack. Если также используется AWS CloudFormation). Это поможет вам исправлять ошибки на множестве серверов и сокращать сценарии, такие как исправление разрешений на сервере A, но забывать делать это на сервере B
• По возможности не выдавайте конкретную версию вашей CMS, PHP или WebServer. Хотя скрытие этой информации не является безопасностью, многие люди сканируют определенные версии различных программ, и чем меньше информации вы предоставляете, тем больше злоумышленнику приходится работать. Это хороший способ убедиться, что вы не один из низко висящих фруктов. Конечно, это ничего не даст тем, кто хочет потратить немного больше усилий, чтобы войти
• Ограничить людей, которые имеют доступ к серверу

В дополнение к тому, что предлагает Дэвид, чем более модульна ваша установка, я имею в виду ограничение доступа к определенным пользователям / группам, созданным специально для одной задачи, и ограничение их объема, тем более безопасным будет ваш стек LAMP. Примером этого является наличие пользователя Apache. для файлов / папок Apache с соответствующими разрешениями, а не в группах, которые могут получить доступ к критическим системным файлам / папкам. Пользователь, который может получить доступ к таблицам MySql, связанным с вашими веб-сайтами, которые вы собираетесь обслуживать, и только к этим таблицам. Кроме того, вы можете ограничить их доступ, чтобы предоставить минимальный объем доступа из вызова PHP. Кроме того, убедитесь, что имя пользователя MySQL, используемое / предоставляемое через файл PHP, не совпадает с именем пользователя или паролем, используемым для другого пользователя.

Что это означает: если пользователь apache или пользователь MySql скомпрометированы, они не могут нанести какой-либо вред за пределами области папок, к которой у apache есть доступ (в случае пользователя apache) и за пределами таблицы (s)/database(s) (в случае пользователя для базы данных MySQL).

Если каким-либо образом пользователь MySQL будет скомпрометирован, он не сможет, например, получить доступ к базе данных, удалить все базы данных из MySQL и испортить все ваши данные. При некоторых обстоятельствах они МОГУТ быть в состоянии отбрасывать таблицы или вставлять информацию в некоторые таблицы в изолированной базе данных, поэтому важно предоставлять доступ к таблицам только там, где это абсолютно необходимо, и предоставлять только необходимые разрешения... если вы не не нужно иметь привилегии удаления таблиц или обновления, а затем не передавать их этому пользователю.

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

Пример времени! Я собираюсь привести системный пример, чтобы упростить идею.

скажем, у вас есть пользователи в вашей системе (root должен быть отключен для безопасности через что-то вроде umod -l или passwd -l и т. д.): Джон, Барни, Теренс и Лиза.

Вы можете создать пользователя в 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/ и т. Д.