Читаю уже вторую статью данного автора с надеждой на что-то вменяемое.
Автор! Иногда лучше не писать ничего, чем писать кое-как.
Ни одной капли полезной информации, всё это можно прочитать в официальной документации mysql и php, причём там это описано гораздо лучше.
— ОЧЕНЬ ВАЖНО: session.save_path = "/var/lib/php5" — это обязательно надо установить так! По стандарту debian именно там должны находиться сессии. Не знаю почему, но в сборке debian эта переменная не выставляется — стоило погуглить 5 минут и найти дебиановский багрепорт, чтобы понять, что такова особенность реализации очистки сессий в дебиане. Всё чистится в кроне. И вот уже эту информацию можно было выложить в статье.
В части MySQL я попробую раскрыть базовые моменты повышения производительности, ибо по умолчанию сервер MySQL настроен очень не эффективно…
…
Сам не являюсь профи по настройке баз данных — не профи, но научу вас, как правильно настроить mysql..
Базовая защита
session.name = SESSID изменил с PHPSESSID на SESSID, для пущей скрытности — no comments.
error_reporting = E_ERROR — уже поправили.
memory_limit = 128M — это то, какое максимальное количество памяти может потребить скрипт. PHP не будет выделать больше памяти, чем указано в этой настройке. Данная настройка указывается в зависимости от задач исполняемых на сервере. Для более точного расчета ресурсов следует закручивать этот параметр как можно сильнее и пытаться писать софт как можно качественнее. — 128 мало для большинства задач, но говоря уже о фреймворках вроде yii.
datadir = /home/mysql — при настройке сделана отдельная директория в /home для mysql с защитой от доступа другим пользователям, кроме mysql. Это сделано, что бы перенести данные из /var/lib/mysql (если я не ошибаюсь) в раздел /home — самый большой раздел диска на сервере, где и хранятся все данные. — Зачем это? Какая защита? От кого? Если это так критично, то напоминаю, что по дефолту в дебиане только пользователь mysql имеет доступ в /var/lib/mysql. Кстати разбиение на разделы более чем странное. Хранить базы в /home очень нестандартное решение.
По mysql весьма поверхностно прошлись. Где переменные innodb_flush_log_at_trx_commit, innodb_file_per_table, sync_binlog ?
Если данная статья будет по вкусу, то собираюсь написать про настройку mail() + postfix + dkim в духе — а может не надо?
Даже на хабре есть несколько таких статей + howtoforge в гугле выходит наверное в первой тройке по запросу «postfix dkim»
соответственно разъясню все нюансы связанное например со стандартами именований принятые у меня — советую почитать стандарты именований принятые во всём мире и следовать им.
У DRBD есть 1 минус — если разъединить ноды и создать на каждой из них по новому файлу(с разными именами), при восстановлении связи всё ломается и приходится руками разрешать «конфликт». Причем нельзя выбрать вариант, когда останутся оба файла. Да, это можно автоматизировать, но суть остаётся прежней — надо выбрать с какой ноды синхронизироваться, а на какой затирать изменения.
В GlusterFS такого косяка нет.
1) на каждом сервере настроить keepalived (который будет перевешивать ip и при необходимости перезапускать сервисы)
2) mysql репликацию в режиме master-master (+auto_increment_offset) на обоих серверах (позволит писать на любой сервер).
3) GlusterFS в режиме distributed+replicated для хранения файлов на обоих серверах (отказоустойчивое хранилище).
Освежив теорию соглашусь с вами, наиболее идеологически правильный вариант это политика ACCEPT по умолчанию + последнее правило в цепочке -j REJECT
Единственное возражение по вашему комменту в предыдущем топике — я думаю, что независимо от протокола нужно отвечать с port-unreachable (что кстати является ответом по умолчанию для REJECT если не указывать дополнительные ключи) т.к при реальной попытке подключения к неиспользуемому порту удалённый хост получит именно такое сообщение. Если отвечать с tcp-reset, злоумышленнику станет ясно, что порт защищён файрволом, а наша цель — выдать минимум информации о нашей системе.
Все что нужно админам или ограниченному кругу лиц не должно висеть на внешнем интерфейсе, а быть доступным только через ssh или vpn.
Абсолютно согласен, добавлю это в статью.
А потом какой-нибудь сервис обновится, или поменяется имя конфига, или веб-приложению надо будет файлы куда-нибудь сохранять или место хранения каких-то временных файлов поменяется, и опять все переконфигурировать… да и можно с дури ssh сломать неудачной конфигурацией. По моему, тут возни больше.
Возни немало, но у нас и цель достойная.
Что касается изменений — само по себе ничего не меняется, всё происходит в результате действий администратора. Просто необходимо взять за правило при любых изменениях на сервере не забывать про соответствующие изменения в его системе безопасности. И всё это документировать.
И по поводу фаерволла — вам поднадобится что-то wget скачать, вы отдельное правило напишете?
Если это разовая необходимость, просто временно сделаю ACCEPT в цепочке FORWARD для нужного сервера. Если скачивание будет периодичным, то да, напишу новое правило.
Или зафаерволлите какой-нибудь ftp, он не сможет посылать ДНС запросы, будет необъяснимо тормозить в случайные моменты времени, и т.д.
Необходимо хоть немного представлять себе структуру сети, в которой настраиваешь файрвол, тогда таких сюрпризов будет меньше.
Кроме того я добавил к пункту про iptables дополнение, о котором просто забыл написать сразу — политику DROP надо включать после полной отладки файрвола и исчезновения записей в сислоге.
Конечно --state RELATED,ESTABLISHED подразумевался мной в пункте (a) Написать все нужные правила
Давайте для ясности я всё же укажу это в тексте статьи.
Спасибо за дополнение.
Ну не знаю, мне кажется это уже излишнее усложнение.
Либо привязка по ip (т.е firewall) либо впн для себя любимого.
Но в этом вопросе думаю все очень индивидуально, и ваш и мой варианты вполне безопасны.
Я бы использовал их вместе. Решения дополняют друг друга.
Смена порта, как я уже отвечал, помогает отсеять простых ботов, сканирующих диапазоны ip адресов.
в общем, статья не содержит никаких конкретных рекомендаций
Смотря что поднимать под конкретными рекомендациями.
Если вы о примерах конфигурации, то об этом я предупредил в самом начале статьи.
То, что бекапы надо делать и лишние сервисы отключить, это и так всем понятно
Я уверен, что это понятно не всем. Статья больше ориентирована на начинающих администраторов, цель была предоставить некий checklist по настройке сервера и подсказать направления для дальнейшего развития.
что касается SELinux — как я понимаю, вещь в теории мощная, но в реальности конфиги к нему устанешь писать быстро.
Это да, конфигурировать его дело муторное, но делать это надо один раз и на одном сервере, а потом можно просто копировать скомпилированные модули с исключениями на остальные сервера.
И про бекап MySQL, опять же, вы не написали даже каковы подводные камни установки слейва на той же машине.
Бэкапы принято выносить за пределы основной площадки в целях обеспечения их доступности при крупной аварии на этой (основной) площадке.
Или вы о каких-то ещё подводных камнях? Возможно я о них и не знаю или забыл написать.
Во-первых, нигде не рассказано про то, как изолировать потенциально опасные сервисы вроде веб-сервера с большим количеством сайтов, или демона Samba от системы
Да, вы правы. Про chroot я совсем забыл.
Хотя в последнее время я предпочитаю выносить такого рода сервисы в виртуальные машины на базе xen.
Так что моя рекомендация — chroot и/или xen, смотря по обстоятельствам.
В-третьих, непонятно, зачем отключать прием/отправку и форвардинг пакетов. Если у вас один сетевой интерфейс, никаого форвардинга не будет, а отключив прием/отправку пакетов, вы во-первых, сломаете все сервисы, во-вторых, нельзя будет скачивать обновления и устанавливать пакеты. Конечно, можно прописать разрешительные правила, но зачем запрещать чтобы снова потом разрешить?
При политике файрвола по умолчанию ACCEPT администратору придётся явно запрещать весь нежелательный трафик.
Это приведёт к большому количеству правил, а соответственно к усложнению системы и замедлению её работы.
Гораздо проще запретить все пакеты и разрешить лишь нужные.
Никакие сервисы не поломаются если следовать описанному мной алгоритму с логгированием пакетов. Вот кстати нашел у себя недочет, забыл написать в этом алгоритме о том, что политику DROP надо включать в самом конце, когда в сислоге уже нет записей. Сейчас исправлю.
Автор! Иногда лучше не писать ничего, чем писать кое-как.
Ни одной капли полезной информации, всё это можно прочитать в официальной документации mysql и php, причём там это описано гораздо лучше.
— ОЧЕНЬ ВАЖНО: session.save_path = "/var/lib/php5" — это обязательно надо установить так! По стандарту debian именно там должны находиться сессии. Не знаю почему, но в сборке debian эта переменная не выставляется — стоило погуглить 5 минут и найти дебиановский багрепорт, чтобы понять, что такова особенность реализации очистки сессий в дебиане. Всё чистится в кроне. И вот уже эту информацию можно было выложить в статье.
В части MySQL я попробую раскрыть базовые моменты повышения производительности, ибо по умолчанию сервер MySQL настроен очень не эффективно…
…
Сам не являюсь профи по настройке баз данных — не профи, но научу вас, как правильно настроить mysql..
Базовая защита
session.name = SESSID изменил с PHPSESSID на SESSID, для пущей скрытности — no comments.
error_reporting = E_ERROR — уже поправили.
memory_limit = 128M — это то, какое максимальное количество памяти может потребить скрипт. PHP не будет выделать больше памяти, чем указано в этой настройке. Данная настройка указывается в зависимости от задач исполняемых на сервере. Для более точного расчета ресурсов следует закручивать этот параметр как можно сильнее и пытаться писать софт как можно качественнее.
— 128 мало для большинства задач, но говоря уже о фреймворках вроде yii.
datadir = /home/mysql — при настройке сделана отдельная директория в /home для mysql с защитой от доступа другим пользователям, кроме mysql. Это сделано, что бы перенести данные из /var/lib/mysql (если я не ошибаюсь) в раздел /home — самый большой раздел диска на сервере, где и хранятся все данные. — Зачем это? Какая защита? От кого? Если это так критично, то напоминаю, что по дефолту в дебиане только пользователь mysql имеет доступ в /var/lib/mysql. Кстати разбиение на разделы более чем странное. Хранить базы в /home очень нестандартное решение.
По mysql весьма поверхностно прошлись. Где переменные innodb_flush_log_at_trx_commit, innodb_file_per_table, sync_binlog ?
Если данная статья будет по вкусу, то собираюсь написать про настройку mail() + postfix + dkim в духе — а может не надо?
Даже на хабре есть несколько таких статей + howtoforge в гугле выходит наверное в первой тройке по запросу «postfix dkim»
соответственно разъясню все нюансы связанное например со стандартами именований принятые у меня — советую почитать стандарты именований принятые во всём мире и следовать им.
В GlusterFS такого косяка нет.
1) на каждом сервере настроить keepalived (который будет перевешивать ip и при необходимости перезапускать сервисы)
2) mysql репликацию в режиме master-master (+auto_increment_offset) на обоих серверах (позволит писать на любой сервер).
3) GlusterFS в режиме distributed+replicated для хранения файлов на обоих серверах (отказоустойчивое хранилище).
Смена порта обманет простых ботов.
Port knocking для отсечения тех, кто целенаправленно изучает именно наш сервер.
Единственное возражение по вашему комменту в предыдущем топике — я думаю, что независимо от протокола нужно отвечать с port-unreachable (что кстати является ответом по умолчанию для REJECT если не указывать дополнительные ключи) т.к при реальной попытке подключения к неиспользуемому порту удалённый хост получит именно такое сообщение. Если отвечать с tcp-reset, злоумышленнику станет ясно, что порт защищён файрволом, а наша цель — выдать минимум информации о нашей системе.
Все что нужно админам или ограниченному кругу лиц не должно висеть на внешнем интерфейсе, а быть доступным только через ssh или vpn.Абсолютно согласен, добавлю это в статью.
А потом какой-нибудь сервис обновится, или поменяется имя конфига, или веб-приложению надо будет файлы куда-нибудь сохранять или место хранения каких-то временных файлов поменяется, и опять все переконфигурировать… да и можно с дури ssh сломать неудачной конфигурацией. По моему, тут возни больше.Возни немало, но у нас и цель достойная.
Что касается изменений — само по себе ничего не меняется, всё происходит в результате действий администратора. Просто необходимо взять за правило при любых изменениях на сервере не забывать про соответствующие изменения в его системе безопасности. И всё это документировать.
И по поводу фаерволла — вам поднадобится что-то wget скачать, вы отдельное правило напишете?
Если это разовая необходимость, просто временно сделаю ACCEPT в цепочке FORWARD для нужного сервера. Если скачивание будет периодичным, то да, напишу новое правило.
Или зафаерволлите какой-нибудь ftp, он не сможет посылать ДНС запросы, будет необъяснимо тормозить в случайные моменты времени, и т.д.
Необходимо хоть немного представлять себе структуру сети, в которой настраиваешь файрвол, тогда таких сюрпризов будет меньше.
Кроме того я добавил к пункту про iptables дополнение, о котором просто забыл написать сразу — политику DROP надо включать после полной отладки файрвола и исчезновения записей в сислоге.
(a) Написать все нужные правилаДавайте для ясности я всё же укажу это в тексте статьи.
Спасибо за дополнение.
Либо привязка по ip (т.е firewall) либо впн для себя любимого.
Но в этом вопросе думаю все очень индивидуально, и ваш и мой варианты вполне безопасны.
Смена порта, как я уже отвечал, помогает отсеять простых ботов, сканирующих диапазоны ip адресов.
Лучше уж vpn настроить для доступа к критичному сервису, если у его пользователей нет статичных ip адресов.
в общем, статья не содержит никаких конкретных рекомендацийСмотря что поднимать под конкретными рекомендациями.
Если вы о примерах конфигурации, то об этом я предупредил в самом начале статьи.
То, что бекапы надо делать и лишние сервисы отключить, это и так всем понятноЯ уверен, что это понятно не всем. Статья больше ориентирована на начинающих администраторов, цель была предоставить некий checklist по настройке сервера и подсказать направления для дальнейшего развития.
что касается SELinux — как я понимаю, вещь в теории мощная, но в реальности конфиги к нему устанешь писать быстро.Это да, конфигурировать его дело муторное, но делать это надо один раз и на одном сервере, а потом можно просто копировать скомпилированные модули с исключениями на остальные сервера.
И про бекап MySQL, опять же, вы не написали даже каковы подводные камни установки слейва на той же машине.Бэкапы принято выносить за пределы основной площадки в целях обеспечения их доступности при крупной аварии на этой (основной) площадке.
Или вы о каких-то ещё подводных камнях? Возможно я о них и не знаю или забыл написать.
Во-первых, нигде не рассказано про то, как изолировать потенциально опасные сервисы вроде веб-сервера с большим количеством сайтов, или демона Samba от системыДа, вы правы. Про chroot я совсем забыл.
Хотя в последнее время я предпочитаю выносить такого рода сервисы в виртуальные машины на базе xen.
Так что моя рекомендация — chroot и/или xen, смотря по обстоятельствам.
В-третьих, непонятно, зачем отключать прием/отправку и форвардинг пакетов. Если у вас один сетевой интерфейс, никаого форвардинга не будет, а отключив прием/отправку пакетов, вы во-первых, сломаете все сервисы, во-вторых, нельзя будет скачивать обновления и устанавливать пакеты. Конечно, можно прописать разрешительные правила, но зачем запрещать чтобы снова потом разрешить?При политике файрвола по умолчанию ACCEPT администратору придётся явно запрещать весь нежелательный трафик.
Это приведёт к большому количеству правил, а соответственно к усложнению системы и замедлению её работы.
Гораздо проще запретить все пакеты и разрешить лишь нужные.
Никакие сервисы не поломаются если следовать описанному мной алгоритму с логгированием пакетов. Вот кстати нашел у себя недочет, забыл написать в этом алгоритме о том, что политику DROP надо включать в самом конце, когда в сислоге уже нет записей. Сейчас исправлю.
wiki.debian.org/SELinux
wiki.debian.org/SELinux/Notes
wiki.centos.org/HowTos/SELinux