Вопрос: Советы по защите сервера LAMP


Это Канонический вопрос о защите стека LAMP

Каковы абсолютные рекомендации по обеспечению безопасности LAMP-сервера?


91
2017-12-14 01:52


Источник




Ответы:


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

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

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

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

М

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


105
2017-12-14 14:50



Я хочу голосовать за этот ответ не менее 10 раз. - user58859
Безмолвный N - с помощью IPTables или внешнего брандмауэра блокирует сетевые подключения только для того, что необходимо для доступа общественности. - Matt
Это должна быть вики сообщества - Brian Adkins
Так легко забыть брандмауэр. Я слышал о ком-то, кто построил веб-сервер для веб-сайта и даже дошел до взлома стека TCP / IP, чтобы выбросить трафик, который не был портом 80. Еще одна вещь, которую упускают из виду, - это ненужные сервисы - если она не нужна для включения, выключите его. - Aaron Mason
@AaronMason: Поздравляем! У вас есть успешный анекдот. Давайте вспомним, что ваша конкретная ситуация сложилась хорошо, но давайте надеяться, что будущие читатели поймут вашу необычную среду. В общем случае этот совет довольно опасен. - Scott Pack


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

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

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


13
2017-12-14 02:23



Я предлагаю прочитать «Руководство по безопасной конфигурации Red Hat Enterprise Linux 5», написанное NSA - ALex_hha
поздно, но недавно я читал, что «не регистрироваться в качестве пользователя root» уже не так уж и много, особенно если вы используете SSH auth на основе открытых / закрытых ключей. - the0ther


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

Брандмауэр

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

SSH и пользователи

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

База данных

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

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

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

7
2017-08-10 08:08





Добавляя к тому, что предлагает Дэвид, чем более модульная ваша установка, тем я имею в виду ограничение доступа к определенным пользователям / группам, созданным специально для одной задачи и ограничивающим их область действия, тем более безопасен ваш стек 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 и т. д.): Джон, Барни, Теренс и Лиза.

вы можете создать пользователя в MySQL с именем bigbird (убедитесь, что вы используете хешированный пароль). У Bigbird только есть привилегии и привилегии обновления, но не отбрасываются и не создаются, и, конечно же, нет , Кроме того, вы создаете другого административного пользователя MySQL с именем garfield для работы с базой данных MySQL и вы удаляете пользователя root из базы данных MySQL, чтобы он не мог быть скомпонован. garfield получил , привилегий в MySQL (фактически, это просто переименование корня).

теперь вы создаете либо группу apache, либо пользователь, и мы будем называть ее apweb2. Appweb2 не является членом других групп, и все файлы / папки для apache хранятся в / home / apweb2 /. Каждый виртуальный хост будет иметь свою собственную подпапку, и каждый из этих хостов будет иметь корневой каталог документа, установленный для этой подпапки. Символы будут отключены, чтобы случайно не предоставлять доступ к остальной части системы.

Кроме того, вы можете ограничить доступ к ssh только определенным пользователям (или определенным группам, я хотел бы поместить их в группу ssh и сделать это единственное, что может использовать ssh).

Кроме того, вы можете выбрать, какие пользователи имеют привилегии sudo, чтобы еще больше ограничить их. Еще один шаг, который вы можете предпринять, заключается в том, чтобы заставить любых пользователей ssh ​​не использовать sudo, вы могли бы создать специальных пользователей, которые могут использовать sudo, которые не могут использовать ssh, так что, как только вы ssh, вам нужно войти в другого пользователя, чтобы доступ к sudo.

Таким образом, путем модуляции каждого сегмента, если один из них скомпрометирован, весь стек не будет скомпрометирован, и вы можете исправить проблему 1 вместо того, чтобы начинать все заново с нуля.


4
2017-07-30 04:49





Я нашел этот документ с SANS.org очень полезным http://www.sans.org/score/checklists/linuxchecklist.pdf


2
2017-08-10 11:50



Добро пожаловать в Server Fault! Как правило, нам нравятся ответы на сайте, чтобы они могли стоять самостоятельно - ссылки отличные, но если эта связь когда-либо ломается, у ответа должно быть достаточно информации, которая по-прежнему будет полезна. Пожалуйста, подумайте над редактированием вашего ответа, чтобы включить более подробную информацию. См. Вопросы-Ответы для получения дополнительной информации. - slm


В настоящее время не игнорируйте виртуализацию контейнеров, а именно Docker, systemd-nspawn и механизмы виртуализации контейнеров, на которых они созданы (пространства имен, группы). Использование виртуализации контейнеров позволяет изолировать процессы, например, если одна из служб подвержена риску, злоумышленник не получит доступ к другим службам.

В случае LAMP можно использовать, например, четыре контейнера Docker с SSH-сервером, Apache, MySQL, PHP-FPM / Python / Perl / и т. Д.


0
2017-07-27 20:00