Что делать с компрометированным сервером?

Как минимум сайты по разным апачам натянуть. Это изолирует их от друга(взломав один к другим доступ не получишь) и кардинально облегчит поиск через что ломают, как ломают и чем ломают. Правда, стартовые скрипты придётся дорабатывать. Ещё не забудь каждому апачу свой pid-файл. В идеале каждому сайту свой php.ini, но уже не помню как это реализовывается.

зы и поставь php mail header patch если спам шлют.

> (openvz)?

А они сами собирают ядро для генты? А то говорят, нормально работают ядра их сборки, свои после секаса всё равно работают не так.

я бы еще заморочился над тем, чтобы сделать эталонную рут фс/часть рут фс, а все изменения - на отдельный диск.
с LVM можно делать такие разделы. и тогда можно будет разные апачи для каждого сайта запускать.

> Это изолирует их от друга
> каждому сайту свой php.ini

CGI/FastCGI же!

а еще лучше - каждому сайту свой отдельный аккаунт, и изолировать их пермишенами. либо, в chroot запихать.

Советую OpenVZ. У меня в него заведено много всяких штук, оверхед небольшой, управлять удобно, можно делать снапшоты.

Некоторые сайты только с mod_php работают, поэтому это не универсальное решение.

А они сами собирают ядро для генты? А то говорят, нормально работают ядра их сборки, свои после секаса всё равно работают не так.

Ну пускай не для генты. Арч нормально поддерживает openvz? И дебиан?

Советую OpenVZ. У меня в него заведено много всяких штук, оверхед небольшой, управлять удобно, можно делать снапшоты.

А можешь посоветовать нормальное руководство (можно и на английском, разумеется)? Какая машина потянет 60 серверов с OpenVZ? Ставить почтовый сервер и сервер бд лучше на те же виртуалки, куда и сайты, или же их лучше не разделять по виртуалкам?

И как после распихиванию по виртуалкам проще обновлять ПО в случае чего (ну вот найдут уязвимость...), централизованно менять некоторые опции в конфигах и т.п.?

Вроде у них только для редхата (==> CentOS): http://wiki.openvz.org/Download/kernel , но вроде они там говорят для дебиана брать от своих мантейнеров. Впрочем, возможно меня ввели в заблуждение, и это вообще испорченный телефон. Хотя центось, наверно, тоже не так плоха в качестве основы.

> Ставить почтовый сервер и сервер бд лучше на те же виртуалки, куда и сайты, или же их лучше не разделять по виртуалкам?

Если уж рассаживаешь - то наверно имеет смысл разделать вообще всё что только можно. Что-бы максимально изолировать на случай взлома.

Вот тут два каких-то описания, большое и маленькое:

http://www.opennet.ru/docs/RUS/virtuozzo/

http://www.qinet.ru/2009/06/75/

Какая машина потянет 60 серверов с OpenVZ?

Без разделения ресурсов, естественно. И нагрузка незначительная. Вот, сами смотрите — http://www.obey.su/munin/e-art.ru/430.e-art.ru-cpu.html http://www.obey.su/munin/e-art.ru/430.e-art.ru-memory.html

Это на такой машине:

hw.machine: i386
hw.model: Intel(R) Pentium(R) 4 CPU 3.20GHz
hw.ncpu: 1
hw.machine_arch: i386

И 2 гигабайта памяти.

Хотя центось, наверно, тоже не так плоха в качестве основы.

Ну хоть центось, хоть что. Главное, что не фряха, меня от неё воротит уже, с неё же ухожу). А в качестве гостевых тогда будут дебианы.

Если уж рассаживаешь - то наверно имеет смысл разделать вообще всё что только можно. Что-бы максимально изолировать на случай взлома.

Действительно, пусть лучше будет и веб, и бд, и почта на каждой виртуалке.

Дебиан, насколько я знаю. в контейнере умеет крутиться. Единственное наверно ограничение, если это можно так назвать, это ядро неизбежно будет как у хоста, просто потому что оно одно (если я всё правильно понимаю).

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

> веб, и бд, и почта на каждой виртуалке.

Может быть есть смысл вынести например db на отдельный контейнер один на всех. А то пяток мускулей с одновременной нагрузкой могут загрузить машину.

Собственно, сломав сайт злоумышленник получит доступ к БД? Видимо её понадобится ломать отдельно, если она на другом хосте.

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

Конечно. Этим openvz от xen и отличается. Последняя — это полная виртуализация. А openvz — частичная, с общий ядром. Зато нагрузки меньше гораздо.

Собственно, сломав сайт злоумышленник получит доступ к БД? Видимо её понадобится ломать отдельно, если она на другом хосте.

Да, хорошая мысль. Только, боюсь, сначала всё равно бд придётся на машинах с вебсерверами держать. Ибо некоторые сайты настолько кривы, что умеют использовать только бд на локалхосте. Да и поди разберись, где на каждом сайте настраивать положение бд. Они все писались лет 7-10 назад.

> А можешь посоветовать нормальное руководство (можно и на английском, разумеется)?

Официальное руководство вполне нормальное: http://download.openvz.org/doc/

Советую обратить внимание на раздел "User beancounters".

> Какая машина потянет 60 серверов с OpenVZ?

У меня C2D 2.66, 4G памяти, Debian Lenny, ЦП не нагружается почти совсем, памяти ест, как настроишь.

> Ставить почтовый сервер и сервер бд лучше на те же виртуалки, куда и сайты, или же их лучше не разделять по виртуалкам?

Это как тебе удобнее.

> И как после распихиванию по виртуалкам проще обновлять ПО в случае чего (ну вот найдут уязвимость...), централизованно менять некоторые опции в конфигах и т.п.?

Как-нибудь так, например:

# for v in 101 102 103 105; do vzctl exec $v aptitude upgrade; done

Я пользовался шаблонами отсюда:

http://download.openvz.org/contrib/template/precreated/

Нареканий нет.

Спасибо за советы.

У меня ещё ситуация осложняется тем, что я собираюсь большую часть из этих 60 сайтов (у которых хозяева-то свои) через месяц-другой пустить в свободное плавание. Т.е. вежливо попросить их выбрать другого хостера и, когда выберут, отдать им их образ openvz.

Может быть, чтобы упростить клиентам поиск хостера в будущем, осилять не openvz вовсе, а xen? Будущее-то за гипервизорами :). Или же проблем с переводом клиента на какого-нибудь крупного хостера и с openvz не будет?

Вообще, в идеале, использовал бы KVM, не будь он такой сырой.

Вообще, в идеале, использовал бы KVM, не будь он такой сырой.

Хотя, если сейчас использую xen, то потом проблем с переходом на KVM не будет. Когда её допилят, она станет мейнстримной вместо xen и с конвертацией образа виртуалки проблем точно не будет.

Берешь Proxmox и ставишь, заходишь через веб морду и получаешь готовую систему без всяких красноглазых гент и прочего.

да я о генте уже и не думаю — или дебиан, или центос, для xen/openvz самое оно

> Может быть, чтобы упростить клиентам поиск хостера в будущем, осилять не openvz вовсе, а xen? Будущее-то за гипервизорами :). Или же проблем с переводом клиента на какого-нибудь крупного хостера и с openvz не будет?

OpenVZ и коммерческий Virtuozzo сейчас довольно часто встречается, а хостеров с Xen я лично не встречал.

> Вообще, в идеале, использовал бы KVM, не будь он такой сырой.

kvm и 60 сайтов - это будет медленно и печально. Его стоит использовать только если нужен не Linux или какие-нибудь извращения.

Не советую держать много инстансов mysql, лучше иметь один. Разделишь права, настроишь адекватное кол-во коннектов, должно поехать.

Как искать? find /www -exec grep mysql_connect {} \; -print и дальше ручками и головой шариться по коду.

Разумеется, каждый сайт перед переводом тестировать на совместимость с выбранной версией php. Насчёт нелокального mysql - не думаю, что возникнут проблемы.

По поводу виртуализации - лично я использую vserver, оверхед минимальный. По докам 60 vserver'ов должно вытянуть, но лично я столько не пробовал. Ядро для debian есть в официальных репах. Насчёт более тяжеловесной виртуализации я бы не задумывался.

а хостеров с Xen я лично не встречал.

Крупных в России — меньше десятка. А за рубежом их полно. http://xgu.ru/wiki/Хостинг_доменов_Xen

kvm и 60 сайтов - это будет медленно и печально. Его стоит использовать только если нужен не Linux или какие-нибудь извращения.

Понимаю. Памяти там 16 гигов. Под каждую виртуалку я выделю 128 Мб памяти с врзможностью повышения до 256 Мб (слава б-гу, это xen умеет, как и openvz) 1 гигабайт тогда в любом случае останется под хост. А проца Xeon E5504, надеюсь, хватит на всех.

Ну а KVM сейчас ещё слишком сыр для поддержания множественных виртуалок (как писал один из местных форумчан, тормозит и глючит под нагрузкой), так что он в любом случае пока не годится. Надо года 3, а то и больше подождать, пока он станет пригодным для продакшна, а пока что xen и только xen в случае гипервизора... Если же нужна виртуализация на уровне ОС, то тут уж openvz.

Не советую держать много инстансов mysql, лучше иметь один. Разделишь права, настроишь адекватное кол-во коннектов, должно поехать.

А чего так? Будет сильно больше памяти просить? Процессор кушать? Или io большой? (это я просто не знаю, опыта нету)

По поводу виртуализации - лично я использую vserver, оверхед минимальный.

Я если и выберу таки system-level virtualisation, то буду использовать openvz. Это всё-таки мейнстрим в этой области, людей над ней побольше работает.

>А чего так? Будет сильно больше памяти просить? Процессор кушать? Или io большой? (это я просто не знаю, опыта нету)

Дисклеймер: практического опыта кручения 60 инстансов mysql на одном хосте не имею.

Я бы доверил шедулинг операций СУБД а не ОС, СУБД виднее что внутри неё происходит. В отношении объёма потребляемой оперативной памяти такой подход должен быть экономичнее. 16 Гб памяти - не слишком много, вероятность ухода в своп лучше уменьшать.

Я бы доверил шедулинг операций СУБД а не ОС, СУБД виднее что внутри неё происходит. В отношении объёма потребляемой оперативной памяти такой подход должен быть экономичнее. 16 Гб памяти - не слишком много, вероятность ухода в своп лучше уменьшать.

Хм... ну тогда да, выделю виртуалку с 1 гигом памяти только под мускль. Тогда ещё, наверное, стоит в отдельную виртуалку запихнуть и exim+dovecot, тогда тоже поменьше жрать должно же.

Тут ещё вариант (чтоб не перенастраивать сайты) — все обращения виртуалок к 127.0.0.1:3306 (т.е. к мусклю) автоматически перенаправлять на виртуалку с мусклем. Ведь iptables так уметь должен?

>все обращения виртуалок к 127.0.0.1:3306 (т.е. к мусклю) автоматически перенаправлять на виртуалку с мусклем

iptables -t nat -I OUTPUT -d 127.0.0.1 -p tcp --dport 3306 -j DNAT --to-destination айпи.сервака.с.мускулом

Правда, не знаю как оно с openvz подружится.

Мне кажется, что использование iptables в этом случае - неоправданный костыль. Такая перенастройка сайта в большинстве случаев сводится к правке одной строчки в конфиге. В других случаях - к однострочнику на sed.

iptables -t nat -I OUTPUT -d 127.0.0.1 -p tcp --dport 3306 -j DNAT --to-destination айпи.сервака.с.мускулом

хостнейм.сервака.с.мускулом надо ведь, айпишник-то общий у всех

Мне кажется, что использование iptables в этом случае - неоправданный костыль. Такая перенастройка сайта в большинстве случаев сводится к правке одной строчки в конфиге. В других случаях - к однострочнику на sed.

Ну так я на крайний случай способ с iptables оставлю.

Не надо усложнять систему, мало ли кому или в каком состоянии её придётся обслуживать ;)

>хостнейм.сервака.с.мускулом надо ведь, айпишник-то общий у всех

При чем здесь хостнейм? Хостнейм — это специфический прикол HTTP/1.1.

При чем здесь хостнейм? Хостнейм — это специфический прикол HTTP/1.1.

Эм? При чём здесь http вообще?

При хостнейме. А вот при чем здесь хостнейм — я не понял :(

Хостнейм к tcp/ip относится, а никак не к http

Насчёт сабжа, а c io проблем не будет? Там 2 почти обычных саташника по 7200 рпм...

>Хостнейм к tcp/ip относится, а никак не к http

Ээ... после резольва имени в айпишник оно никак и ни на что не влияет. Так везде, кроме HTTP 1.1.

Или я что-то упустил?

Так, значит я серьёзно ошибался. Млин. А где можно почитать по теме?

сам нашёл — http://en.wikipedia.org/wiki/Virtual_hosting#Name-based

> хостнейм.сервака.с.мускулом надо ведь, айпишник-то общий у всех

Не хостнейм. hostname-based правила iptables умеет, но сильно не рекомендуется это использовать раз, а в твоём случае это бессмысленно два, так как интерфейсы будут в бридже, либо будет маленькая виртуальная сеть с файрволом на HN, который и будет распределять запросы. Альзо, в таком случае туда же (или на отдельную виртуалку) наверное стоит поставить nginx - это если у тебя будет 1 ip и куча хостнеймов на нём. Nginx-то как раз сможет определить, какой из виртуалок направить твой запрос (по заголовку Host: в HTTP 1.1, как пишет ув. nnz).

маленькая виртуальная сеть с файрволом на HN

это как?

nginx - это если у тебя будет 1 ip и куча хостнеймов на нём. Nginx-то как раз сможет определить, какой из виртуалок направить твой запрос (по заголовку Host: в HTTP 1.1, как пишет ув. nnz).

ясно.

маленькая виртуальная сеть с файрволом на HN

это как?

я имею в виду «что такое HN?»

> я имею в виду «что такое HN?»

HN - Host Node - основной сервер, на который ставятся виртуалки.

Так. У меня 1 IP. 1 машина, на ней 60 виртуалок. Тогда работать оно будет следующим образом. Устроен NAT, host node является роутером, а каждой виртуалке с помощью brctl присвоей свой внутренний IP'шник. Правильно я понимаю? Тогда единственный путь раздать им домены — использовать (в целях безопасности — на отдельной виртуалке) один на всех nginx, который бы и распределял запросы? Правильно понимаю? И другого пути нет (помимо покупки IP'шников)?

По джабберу разговор окончили. В общем, ответ - да, только если не использовать на nat роутинг по хостнеймам, но последнее опасно, медленно и нежелательно.

А sshd и ftpd надо будет рассовать по разным портам, а на NAT настроить соответственный проброс.

Что будут повышенно жрать 60 ядер (xen) в сравнении с одним (openvz) — проц? память? И какова разница в требованиях вообще?