Чем опасен shared хостинг

[Fox Mulder]

Хорошо, спасибо. Так что же мне делать пока я не могу переехать под отдельный апач. Как защититься?

[alexei1966]

Значит злоумышленник с правами веб-сервера не может прочитать конфиг, а PHP с теми же правами может? Похоже стоит ещё больше запутаться...

О каком конфиге идет речь? Да, скрипт PHP с правами веб-сервера прочтет файл conf_global.php. Но пароля в явном виде там уже НЕТ. Пароль берется из переменной, которую передает веб-сервер скриптам, запущенным с ДАННОГО ВИРТУАЛЬНОГО ХОСТА. А поскольку скрипт кракера запущен не из каталога нашего виртуального хоста, то и переменной он не получит.

 

Пароль теперь хранится в конфиге Апачи httpd.conf (virtualhosts.conf и т.п.), который доступен только root.

[Sannis]

Теперь понятно, спасибо, не углядел

[MiksIr]

скины править на тестовом и заливать готовые. Это более практично и прозрачно, имхо.

Для большинства обычных пользователей (которые составляют большинство пользователей шаред хостинга) это неприемлемо. Думаю, сами понимаете почему. И значит это сводит "на нет" всю описанную защиту.

 

ЗЫ: а вообще метод похож на установку антивируса от одного вируса. Спокойствие может дать.. может даже защитить. Но все-равно сопрут. Но конкретно от этого вируса защищает хорошо, согласен. А вот потенциальные косяки от случайного банального phpinfo() - запросто получить могут.

 

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

Изменено 6 Апреля 2009 пользователем MiksIr

[Sannis]

Для большинства обычных пользователей (которые составляют большинство пользователей шаред хостинга) это неприемлемо. Думаю, сами понимаете почему. И значит это сводит "на нет" всю описанную защиту.

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

А тестовый форум имхо должен любой иметь, нефига на рабочем моды ставить сразу. А кто этого не понимает — ССЗБ

[MiksIr]

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

[Sannis]

Ну собственно chmod-ом на папку кеша.

[MiksIr]

Э... если кеш сгенерен веб-сервером, то владелец файлов кеша - вебсервер, а значит от его имени можно сменить права на запись обратно и спокойно туда записать (на корневую папку где кеш достаточно возможности просмотра). Постоянная смена прав на фалы кеша поможет, если изначально будет их владелец не вебсерер, а юзер (надеюсь, при перегенерации файлы просто перезаписываются, а не удаляются и создаются заново). Т.е. человеку нужно пойти в кеш, поменять всем файлам права на запись, произвести действия в админке с шаблонами, пойти и сменить права обратно. Да, интересно, сколько людей готовы на это в борьбе с гипотетическим врагом, и сколько из этих готовых будут постоянно забывать менять права... защита не должна зависить от "Забыл/Вспомнил" - она должна быть или фоновой или не оставлять пользователю выбора.

 

ЗЫ: а самое главное, из-за чего весь сыр бор... я так и не понял - человеку показали пароль на базу или пароль на админку.

[Sannis]

Обычно пользователь webserver и ftp_login разные, так что можно от имени второго поставить 600, тогда первый не должен иметь прав на перезапись. Ну а дальше всё снова утыкается в то, как же делает хостер

 

Т.е. человеку нужно пойти в кеш, поменять всем файлам права на запись, произвести действия в админке с шаблонами, пойти и сменить права обратно.

Похоже вы меня не поняли Через АЦ скины правятся на тестовом форуме, возможно локальном, где не обязательно так следить за правами. А после этого уже готовый кеш заливается на рабочий сервер, где можно один раз поставить на него 600 от имени ftp и дальше заливать файлы поверх старых.

[MiksIr]

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

Кстати, лень проверять - ссылочка phpinfo() в админке вторичным админам доступна?

И вообще, уж извините, получается как-то так

- Мне сказали, что у меня жена умерла

- О, а она под многоэтажными домами проходила? Ну это точно кирпич упал на голову. (Далее идет обоснование, почему вероятность падения кирпича на голову рядом с многоэтажками выше, чем у маленьких домов)

- О, ужас, что же делать?!

- Ну, во-первых каска. Желательно несколько касок, еще есть вот такие скафандры, их можно надевать, но они громоздки - в метро не пройдут, но их нужно надевать когда будете мимо дома проходить.

...

Пусть лучше Алексей ткнет пальцем в свой же список - http://internet.cnews.ru/hosting/stat/ и покажет хостинг, который криво настроен и подвержен раскрытию информации.

[G*g]

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

Кстати, лень проверять - ссылочка phpinfo() в админке вторичным админам доступна?

всем в группе root (4).

 

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

 

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

тема уже ни о чем идет. обос*али shared-хостинг, извините за выражение, но при этом ничего толкового не написали.

 

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

 

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

[Arhar]

ничего толкового не написали

http://www.ibresource.ru/forums/index.php?...st&p=341962

что в этом нетолкового?

совершенно адекватный алгоритм

1) мы не можем залить ни одного инородного файла, кроме как по фтп, значит не можем внедрить код

2) мы не можем изменить ни одного файла, значит не можем внедрить код

3) мы можем прочесть conf_global.php, но там нет пароля

4) чтобы прочесть пароль, нам нужно вызвать phpinfo()

5) чтобы вызвать phpinfo(), нам нужно :

5.1) залить/изменить файл на сервере, вставив туда вызов - обрубается пунктами 1 и 2

5.2) иметь группу root админов ipb - тогда мы имеем доступ к консоли SQL в админке и нам уже нахрен не нужен пароль от бд - творим что хотим

 

комментарий к 1) - если мы имеем доступ к фтп нам также мало чем можно помешать

[Sannis]

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

...

+1.

[alexei1966]

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

 

"Черного списка" хостеров не будет, потому что объективные данные по взломам набрать нереально. Любая статистика взломов свято охраняется хостером по понятным причинам. Никто не даст клиенту прямой доступ к логам веб-сервера на совместном хостинге. А ведь в подобных случаях надо анализировать еще несколько логов, а также смотреть, что происходило в файловой системе. У меня, например, регулярно запускается утилита контроля за изменениями файлов по всей FS. Так что можно хоть гипотетически увидеть, что в каталоге у пользователя malefactor появился странный скрипт crack_ipb.php, который он на следующий день потер. Ну и много ли это даст?.. Правильный кракер быстро копирует свои программы под нейтральными названиями, быстро получает нужную информацию и выходит, "прибив тушку".

 

Насчет "прямых рук" админов. Впечатление примерно двухлетней давности. Крупнейший мировой провайдер - bluehost, около 400 тысяч клиентов. Мой знакомый (не администратор, программер) около года пользовался его услугами, доволен, как крокодил. Короче, я прикупил у "голубого" тарифный план. Продержался месяц, потом потребовал мани-бэк. Называть после этого некоторых наших хостеров помойками у меня язык не поворачивался... Плюс совершенная невозможность достучаться до технического персонала. Весь их call-center для уменьшения расходов распределен в третьих странах - сначала тебя переключают на Чандру ("мэй ай хельп ю?" - дальше тишина, потому что я английский знаю лучше его), потом на Ли, потом вообще непонятно на кого. Причем, похоже, некоторые из этих Чандр считаются у них системными администраторами...

 

В общем, спасение утопающих - дело рук самих утопающих. Если уж занесло на shared hosting - лучше проделать описанные профилактические работы. Они, на самом деле, совершенно стандартные.

 

Также очень полезно установить утилиту для контроля за целостностью файлов, например, ViperDB:

http://www.resentment.org/projects/viperdb/index.html

 

Тогда если в вашем каталоге появятся незапланированные файлы, вы об этом узнаете. Аналог есть в админке, но он по понятным причинам контролирует не все.

 

Далее, в каталог admin/ неплохо положить файл .htaccess с инструкцией

 

SSLRequireSSL

 

Тогда работа с админкой пойдет по https, что резко уменьшает возможность утечки информации по неосторожности: браузеры при работе по https по умолчанию становятся паранойяльно подозрительными.

 

И все-таки, возвращаясь к теме ветки: для разных потребностей и разных программ существуют свои виды хостинга. Shared создавался изначально для статических файлов и каталогов read-only. Фактически мои рекомендации - попытка такую структуру и права создать для IPB, а это качественно другая программа, где есть и конфиденциальные данные, и каталоги для записи. Поэтому - все же другие виды хостинга.

[MiksIr]

Ну у вас то статистика есть такая, правда? Раз вы все это утверждаете, можете сказать - какой процент из списка лично вы проверили и нашли дыры... или хотя бы ссылки на репорты о таких дырах. Это очень плохо, что в хостинге bluehost помойка и плохой саппорт, но к данному вопросу отношения не имеет.

Все, что вас просят - обосновать информацию о дырах. Единственный источник, что прозвучал от вас - это какие-то таинственные форумы где кто-то там общается. Что бы защищаться, нужно что бы было от чего, правда? "alexei1966 на форуме сказал" - это не та причина, по которой стоит это делать. Так покажите примерами - "вот тут и тут было поломано потому что php от юзера вебсервера работает".

 

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

А кто сказал, что его в этом случае не нужно менять?

Изменено 8 Апреля 2009 пользователем MiksIr

[Serenity]

...

5. Далее просим хостера внести в конфигурационный файл Апачи для основного виртуального хоста форума строчку:

<VirtualHost 1.1.1.1:80>

SetEnv DBPassword mypass

 

6. В файл conf_global.php меняем строчку:

$INFO['sql_pass'] = $_SERVER["DBPassword"];

...

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

Алексей, огромное спасибо за 5 и 6 пункт! Очень сильно обрадовалась увидев такое простое и элегантное решение, а вот что касается изменения прав у скриптов и каталогов IPB, мне кажется это хоть и не обходимое решение, но гм... как сказать, не эстетично что ли, так как при нем часть функционала форума будет не доступна без обратного изменения FS (о чем вы нас предупреждаете), мб вы можете предложить другой способ?

 

Сразу оговорюсь, что мне это все интересно скорее из любопытства (получаю 2во по специальности защита информации), чем из реальной необходимости, так как работодатель арендует VDS для маленького сайта и форума на 20ть человек, с которыми я работаю.

 

P.S. Главное, чтобы конфигурационный файл Апачи у хостера не был открыт для чтения "прочими" ...

а можно чуть чуть по подробнее, кого вы подразумеваете под "прочими"? Заранее спасибо.

 

P.P.S. MiksIr, вы видели тему из которой выросла данная? Если нет, то посмотрите сюда.

 

P.P.P.S. А в целом я согласна с рассуждениями alexei1966. Да, на shared-хостинг поставить можно. Да, при этом существует реальный риск безопасности, и это можно утверждать хотя бы из-за невозможности/нежелания/неумения узнать о состоянии настроек у выбранной хост площадки. Но при этом, уверена, что не стоит так же забывать о "принципе разумной достаточности".

Изменено 8 Апреля 2009 пользователем Serenity

[G*g]

У меня, например, регулярно запускается утилита контроля за изменениями файлов по всей FS. Так что можно хоть гипотетически увидеть, что в каталоге у пользователя malefactor появился странный скрипт crack_ipb.php, который он на следующий день потер. Ну и много ли это даст?.. Правильный кракер быстро копирует свои программы под нейтральными названиями, быстро получает нужную информацию и выходит, "прибив тушку".

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

 

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

 

Также очень полезно установить утилиту для контроля за целостностью файлов, например, ViperDB:

http://www.resentment.org/projects/viperdb/index.html

и это после ваших же слов о доп. нагрузке на сервер? и мы вообще не дедик, а шаред обсуждаем. но за совет для первых все равно спасибо. хотя я бы себе такое чудо не поставил по вышеописанным причинам.

 

Далее, в каталог admin/ неплохо положить файл .htaccess с инструкцией

 

SSLRequireSSL

 

Тогда работа с админкой пойдет по https, что резко уменьшает возможность утечки информации по неосторожности: браузеры при работе по https по умолчанию становятся паранойяльно подозрительными.

дело.

 

ничего толкового не написали

http://www.ibresource.ru/forums/index.php?...st&p=341962

что в этом нетолкового?

толк есть в его словах, бесспорно. но голословность про то, какой плохо шаред-хостинг нехорошо. и тему бы лучше переименовали не в "Чем плох shared хостинг", а "Чем опасен shared хостинг". Он не плох же. Просто могут на неизвестных или новых хостингах содержаться описанные в теме опасности.

[MiksIr]

P.P.S. MiksIr, вы видели тему из которой выросла данная? Если нет, то посмотрите сюда.

Угу, где даже не сказано, какой пароль ему "показали" - от админки или от базы (а сделать дамп таблицы паролей из админки не проблема). Зато сразу навесили - "а, это через хостера слили"... "ууу, какой ужас" отдалось эхом. Писец, просто.

[Serenity]

... и тему бы лучше переименовали не в "Чем плох shared хостинг", а "Чем опасен shared хостинг". Он не плох же. Просто могут на неизвестных или новых хостингах содержаться описанные в теме опасности.

поддерживаю.

 

MiksIr, пока гром не грянет, мужик не перекреститься, кажется так говорят. Не ужели Вам не кажется, что быть предупрежденным о подобной потенциальной уязвимости явно лишняя и не нужная информация?

[alexei1966]

Алексей, огромное спасибо за 5 и 6 пункт! Очень сильно обрадовалась увидев такое простое и элегантное решение, а вот что касается изменения прав у скриптов и каталогов IPB, мне кажется это хоть и не обходимое решение, но гм... как сказать, не эстетично что ли, так как при нем часть функционала форума будет не доступна без обратного изменения FS (о чем вы нас предупреждаете), мб вы можете предложить другой способ?

 

Сразу оговорюсь, что мне это все интересно скорее из любопытства (получаю 2во по специальности защита информации), чем из реальной необходимости, так как работодатель арендует VDS для маленького сайта и форума на 20ть человек, с которыми я работаю.

 

P.S. Главное, чтобы конфигурационный файл Апачи у хостера не был открыт для чтения "прочими" ...

а можно чуть чуть по подробнее, кого вы подразумеваете под "прочими"? Заранее спасибо.

Увы, если мы оставим возможность записи в каталоги основного виртуального хоста:

 

1. Злоумышленник сможет запортить там файлы;

 

2. Он сможет записать туда скрипт и получить значение переменной $_SERVER['DBPassword'], которую мы от него пытаемся скрыть.

 

"Прочие" - это третья группа прав на файлы/каталоги в Юниксе: 1-я - user, 2-я - group, 3-я - others (или world). К сожалению, файлы из каталога /etc/ обычно открыты для чтения всеми, в том числе и httpd.conf.

 

Насчет уменьшения функциональности админки - а вы что, обновления файлов IPB сразу на рабочем сервере делаете?? По-хорошему у вас должна быть тестовая версия форума, все обновления сначала делаете на ней, потом переливаете обновленные файлы на рабочую машину. Поскольку переливаете через FTP, описанная схема никак не помешает.

 

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

 

ЗЫ. Тему я бы действительно переназвал - например, "Какой вид хостинга оптимален для IPB?"

 

Ответ троллям (т.е. разговор с самим собой ).

 

1. Как именно произошел взлом, точно не скажет никто. Кракеры не рисуют черную кошку и не оставляют описаний технологии взлома. Но мы знаем, что они получили базу данных, однако ни разу не заходили в IPB как администраторы. А ведь для кракеров пакостной разновидности (в смысле - не кракеров-коммерсантов) самый кайф как раз в том, чтобы оставаться на ресурсе месяцами, издеваясь над администратором форума. Значит, пароль они получили только к базе данных, а чтобы слить БД, нужен обычно запуск скрипта с локальной FS.

 

Все это указывает на запуск локального скрипта. Как они этот скрипт записали? Если через IPB, то они должны были войти как админы форума, а входов не было. Значит, скорее всего - через соседний хост на совместном виртуальном хостинге.

 

Правда, остается еще такой сценарий: стибрили пароль админа форума, зашли в админку, слили БД, потом тщательно вытерли все следы присутствия (для этого надо знать конкретную версию IPB, чтобы знать, где хранятся логи), и... побежали хвастаться к владельцу форума, который, конечно, первым же делом сменит свой пароль на админку. Нелогично. Кстати, заходы в админку можно отследить и по логам Апачи.

 

2. Еще раз насчет "черного списка провайдеров" - объективно этот список не может составить никто. Тем более, что все меняется: взяли на работу нового администратора, он заодно и какие-то дырки закрыл. Открывать жалобную книгу на хостеров в форуме IPB?? Идите на другие форумы, тот же hostobzor.ru. Есть также закрытые форумы хостеров, существуют и "черные списки" клиентов - если вы к ним имеете доступ, то чего спрашиваете?

 

3. Зарубежный хостинг: для сведения всех, в 2008 году началась массовая миграция хостинга доменов в зоне РУ за рубеж (сейчас уже около четверти доменов). Потому что в России бессмысленно дорого. У меня, к слову, сервер арендован в США у самого крупного их провайдера по dedicated и colocation. Обходится в 4 раза дешевле. Кстати, причина миграции прозаическая: практически исчерпались физические ресурсы российских площадок, новые сервера некуда ставить физически. Вообще физически почти все хостерские сервера России стоят в Москве и немного в Питере; в провинции какие-то крохи. Невыгоден хостерский бизнес по сравнению с торговлей водкой и ботинками...

 

4. Насчет нагрузки на хостинг, который якобы дают утилиты контроля за целостностью файлов. Смеялся. Маленький скрипт на Перле, который достаточно запускать раз в сутки и который на пользовательском каталоге отрабатывает за несколько секунд. Если хоть в какой-то степени опасаетесь взлома - ставить непременно!! И вообще - как иначе собираетесь следить за тем, что происходит в недрах IPB? У меня, например, там 4 с лишним тысячи файлов. Вручную пересчитывать, что ли? А кракеры в чужих записываемых каталогах часто устраивают целые собственные склады.

[MiksIr]

MiksIr, пока гром не грянет, мужик не перекреститься, кажется так говорят. Не ужели Вам не кажется, что быть предупрежденным о подобной потенциальной уязвимости явно лишняя и не нужная информация?

Потенциальная язвимость есть. Как и потенциальная возможность развития у вас раковой опухоли. Вы пьете профилактические препараты?

 

Понимаете, ситуация выглядит так:

- человек сообщил о взломе, причем ничего толком не сказал (даже о том - какой пароль украли);

- пришел алексей и заявил - проломили хостинг потому что все шаред хостинги дырявые;

- потом была теория - почему это потенциально возможно (с кучей ошибок, которые бы человек реально занимающийся такими вопросами не допустил бы);

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

- далее последовала теория о том, как защитится от всего этого.

 

Теория то хорошая, но практике (что у алексея не сильная сторона) тут две проблемы. Первая - придется отказаться от правки шаблонов из админки. Т.е. каждый пользователь форма должен поставить себе апач/пхп/базу, развернуть локально форум, все изменения делать только там (включая даже цвет в css файле) и потом заливать на хостинг. Это красиво, но работать для большинства пользователей не будет. Вторая - это пресловутая строчка в конфиге апача. Но, можете поверить, можете проверить, такой услуги я не встречал, а уговорить любого крупного хостера сделать это специально для вас - нереально (и это правильно, так как начиная подтачивать системные вещи под каждого пользователя в итоге к появлению какой-то уязвимости и прийдешь). Это пройдет с маленьким хостером, типа "вот купил я сервер" - однако именно таких хостеров в плане уязвимостей и следует бояться - с этим вроде все согласны.

 

А потом, когда человека спросили - а на чем, собственно, основывается информация о дырявости хостингов (не теория, а практика), человек ничего ответить не смог, обозвал форумными тролями и продолжил свои домыслы "что да почему случилось".

... ох, извиняюсь, форумным тролем он себя называл, судя по цитате "Ответ троллям (т.е. разговор с самим собой"

 

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

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

 

На этом, дабы и правда не кормить тролей, ретируюсь. Если кто-то готов мне привести такую уязвимость у хотя бы топа30 наших хостеров - пишите, оформим как исследование безопасности, сделаем тестовые площадки, дыру потом сдадим хостеру, дабы никакой уголовщины, а я приду сюда и покаюсь "ах, есть такие дыры у нормальных хостеров, всем следовать алгоритму алексея".

Изменено 8 Апреля 2009 пользователем MiksIr

[WildRAID]

Вы по кругу ходите. Честно.

[alexei1966]

Ага, флуд пошел. Может, доверить модераторам форума наши бесконечные препинания потереть, сделать резюме и закрыть ветку?

[Arhar]

Можно просто закрыть, выводы здесь довольно простые, как и всегда:

Что в плане нагрузки, что в плане безопасности, для хорошего качественного форума на движке IPB нужна отдельная машина.

А тему надо закрыть, ибо придут нубы и начнут задавать одни и те-же вопросы - "а куда эта писать", "у миньа ни рапотает" и т.д.