Перейти к содержимому


Фотография

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

Форумы IBResource

  • Закрытая тема Тема закрыта
Сообщений в теме: 73
alexei1966
  • Участники
  • Cообщений: 57

Отправлено

Двумя руками "за" выступление WildRAID! Если вы выставляете свой сайт в Интернет, то должны быть готовы к тому, что однажды до него кто-то доберется с "черного хода". Это как вождение автомобиля - за 10 лет вождения непременно будут и вмятины, и столкновения - не ты, так в тебя... Надо к этому относиться по-философски. Быть психологически готовым к взлому, а при обнаружении следов взлома - спокойно действовать.

Я тут просмотрел структуру IPB 2.3.6 - она, увы, не модульная. И она предполагает существование каталогов с возможностью записи внутри этого дерева. Тем не менее некоторую пакость кракерам можно сделать - конечно, если хостер поможет. ;) Сразу говорю - не панацея, но хоть что-то.

================
1. Обычно в тарифном плане есть возможность заводить несколько виртуальных хостов. Заводим кроме основного forumtest.domain.ru хост forumtestuploads.domain.ru.

2. Передвигаем (mv) туда каталог uploads - это единственный каталог IPB, который должен быть постоянно открыт на запись веб-сервером.

3. Заходим в админку - "Утилиты и настройки" - "Общие настройки". Меняем "URL к директории для загрузок" и "Путь к директории 'upload'" на новые - forumtestuploads.domain.ru и что-то вроде /www/petrov/forumtestuploads.domain.ru/html/uploads.

4. Теперь все файлы и каталоги, оставшиеся в каталоге IPB, делаем доступными только для чтения. С этим могут быть проблемы, поэтому лучше попросить хостера сделать из корневого каталога вашего виртуального хоста что-то вроде:
find ./ -type d -exec chmod 550 '{}' \;
find ./ -type f -exec chmod 440 '{}' \;

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

<VirtualHost 1.1.1.1:80>
SetEnv DBPassword mypass

6. В файл conf_global.php меняем строчку:
$INFO['sql_pass'] = $_SERVER["DBPassword"];

7. Просим хостера поменять владельца всех файлов в каталоге обоих виртуальных хостов на вашего пользователя, т.к. некоторые каталоги и файлы имеют по умолчанию владельцем apache, что-то вроде:
chown petrov ./* -R

================

Что получаем в итоге.
1. Основные скрипты форума отделены от подгружаемых данных и имеют права только на чтение. Поэтому кракер не сможет их модифицировать. Это имеет и обратную сторону - вы не сможете подгрузить через админку новые языковые файлы, рисунки для оформления и т.п., пока не измените атрибуты у каталогов. С другой стороны - это не каждый день надо. Зато спать будете спокойно. :D

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

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

MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

А что помешает человеку, загрузившему что-то свое сделать chmod 777 на файлы форума?

alexei1966
  • Участники
  • Cообщений: 57

Отправлено

А что помешает человеку, загрузившему что-то свое сделать chmod 777 на файлы форума?

Поконкретнее, пожалуйста. А то много догадок приходится делать насчет вашего "человека, загрузившего что-то свое". :D Что за "человек", какие у него права, что именно и в какой каталог он грузит? И каким образом он потом меняет права у чужих файлов?

MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

Это вы поподробнее, что своим шаманством с атрибутами на чтение хотите сделать - защита от чего именно это?

find ./ -type d -exec chmod 550 '{}' \;
find ./ -type f -exec chmod 440 '{}' \;

Кстати, chmod -R a-w * - так, пожалуй, пишется правильно

alexei1966
  • Участники
  • Cообщений: 57

Отправлено

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

MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

Вы изложили "что нужно сделать", а я спрашиваю - "зачем и как это поможет".

alexei1966
  • Участники
  • Cообщений: 57

Отправлено

Вы изложили "что нужно сделать", а я спрашиваю - "зачем и как это поможет".

По-моему, я один раз уже объяснил. Но если вы не поняли - объясняю лично вам еще раз другими словами. :D

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

2. Кракер не может более ничего испортить в каталогах cache/, так как они также закрыты от записи.

3. Фактически все, что теперь доступно злоумышленнику с правами веб-сервера - это потереть или заменить файлы, выгруженные пользователями в виде вложений в каталог uploads/. Но это беда уже относительно небольшая. Ни писать на форуме, ни рушить его структуру, он не может - необходимы другие права.

Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

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

Что-то я запутался :D А PHP с чьими правами запускается в вашем варианте?

2. Кракер не может более ничего испортить в каталогах cache/, так как они также закрыты от записи.

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

alexei1966
  • Участники
  • Cообщений: 57

Отправлено

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

Что-то я запутался :D А PHP с чьими правами запускается в вашем варианте?

Веб-сервера. Мы рассматриваем виртуальный совместный хостинг (shared).

Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

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

MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

Так еще раз - в чем смысл установки r-x на файлы владельца petrov, если запускаемый злоумышлеником скрипт имеет владельца apache.

Сообщение отредактировал MiksIr: 06 Апрель 2009 - 21:31


alexei1966
  • Участники
  • Cообщений: 57

Отправлено

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

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

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

Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

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

MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

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

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

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

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

Сообщение отредактировал MiksIr: 06 Апрель 2009 - 21:52


Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

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

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

MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

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

Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

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

MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

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

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

Sannis
  • Команда форума
  • Cообщений: 11 877
  • http://sannis.ru
  • Город:Москва
  • Интересы:Фотография, физика, высокопроизводительные системы, прикладное программирование, спортивный туризм.

Отправлено

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

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

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

MiksIr
  • Участники
  • Cообщений: 73
  • http://
  • Город:msk.ru

Отправлено

Я понял. Я так же представляю, что никто это делать не будет. А уж делать это ради гипотетической защиты...
Кстати, лень проверять - ссылочка phpinfo() в админке вторичным админам доступна?
И вообще, уж извините, получается как-то так
- Мне сказали, что у меня жена умерла
- О, а она под многоэтажными домами проходила? Ну это точно кирпич упал на голову. (Далее идет обоснование, почему вероятность падения кирпича на голову рядом с многоэтажками выше, чем у маленьких домов)
- О, ужас, что же делать?!
- Ну, во-первых каска. Желательно несколько касок, еще есть вот такие скафандры, их можно надевать, но они громоздки - в метро не пройдут, но их нужно надевать когда будете мимо дома проходить.
...
Пусть лучше Алексей ткнет пальцем в свой же список - http://internet.cnews.ru/hosting/stat/ и покажет хостинг, который криво настроен и подвержен раскрытию информации.




Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных