hume

Рейтинг
46
Регистрация
17.10.2012
Если сайт имеет дыру, позволяющую запускать любой код - то ничего заливать не надо. Сольют и так.

Прочитайте плз всю ветку прежде чем баянить.. Вопрос не про слив.

hume, вы просто не понимаете что такое права доступа и как они работают. 666/644/600 это не все что существует. Советую очень внимательно изучить.

Спасибо за ссылку, изучим, не претендую на всезнайку )

А после подумать кем тут выступает Apache, кем PHP, и что вам дают и те и другие права как при обычном модуле Apache, так как и при MPM-ITK.
А главное помните, что на файлы/папки нужно ставить минимально необходимые права и ни на грамм больше!

Как раз из за этого у меня и возмущения. MPM-ITK дает слишком много прав php скриптам. Я бы сказал даже что при ITK вообще не важно какие права стоят, они по умолчанию "максимальные"(что 600 что 666 что 777, т.к. скрипт может делать что хочет, хоть себя переписать).

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

Так и есть, разбито по "группам".

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

Если скрипт физически не может никуда записать, ни в одну директорию. А если куда то и может(upload дира), то там лежит .htaccess запрещающий запуск скриптов - и как ему шел зальют? А вот с ITK запросто, в любую диру )

то все абсолютно бесполезно, если у вас в движке дыры. Взломают через дыру и сольют ваш сайт с базой даже со скриптами в режиме только для чтения.
Другое дело - если у вас говносайты, за которыми лень следить. Ну тогда тут классический mpm prefork.

А если не у нас в движке, а в вордпресс, дле и тому подобных? Нет возможности сидеть и следить за каждым, проще не давать всем скриптам доступ на запись. Кроме того проблем у меня никогда небыло с паблик движками, т.к. права были распределены нормально, без лишних возможностей. А сейчас когда появился ITK сразу зашелили.. Можете хоть сколько говорить что так удобнее и безопаснее, но для меня факт на лицо ) Да и задачи у всех разные..

Кому не лень, расскажите плз какие права при ITK по вашему мнению должны быть на файлы/директории скажем для типичного сайта на wordpress?

Сейчас считается, что нормально.
От сайта зависит. Вы разве не видели всяких там закачек файлов, самообновляющихся скриптов, конфигураторов?
Хостеры привыкли так делать чтобы не иметь проблем со всеми этими вещами. А вы, конечно, можете сделать как вам нравится.

Все это видел, всегда удивляло зачем открывать такую "дыру", обязательно кто нибудь воспользуется, особенно если движок не свой, а один из известных. Тогда понятно почему столько жалоб на заражения сайтов. Имхо давать php скрипту карт бланш очень опрометчивое решение.. Я привык к тому что изначально все запрещено, разрешаешь запись только туда куда это действительно нужно. Насчет авто-обновлений норм движки поддерживают ftp(в автоматическом режиме обновляют по ftp) и им не требуются такие "широкие полномочия".

Не надо вешать все сайты под одного юзера. Все корректно, когда скрипт имеет доступ ко всему нутру сайта, а вот права 777 - это совершенно некорректно, так как к этим файлам доступ будут иметь и соседние юзеры тоже.

Ну конечно, на 20 сайтов создадим 20 пользователей, мега круто и удобно )

И не заморачивайтесь шелами, шел загружают через дырку в движке, ничего не мешает взломщикам из php скрипта заюзать функцию chmod и выставить нужные права на любой из файлов, так что все ваши потуги и заморочки напрасны.

Как раз таки очень даже не напрасны и мешают выполнить chmod, вы попробуйте. Если запуск не от владельца чтобы исполнить chmod нужно чтобы были права 666. Ваше мнение ошибочно в данном случае. Даже если заливают шелл, кроме как посмотреть больше ничего не могут сделать. А те каталоги в которые можно заливать из вне(файлы, картинки и т.п.) можно и нужно закрывать от исполнения php скриптов в нем, если в этом нет особой потребности.

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

Действенное решение не пускать php скрипты "в разгул" с наивысшими правами. Обновление ПО не спасет, каждый день не станешь следить, тем более если сайтов 10-20-30, в итоге это приведет к тому что по факту заражения уже станешь обновлять..

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

Проблема в том что по умолчанию при правах 600 php скрипт имеет доступ ко всему нутру сайта(может изменять/создавать любые файлы) - разве это нормально? Мне так через dle залили шел и в рамках одного юзера покоцали и другие сайты которые под этим юзером.

Пофиксилось так:

Вместо "AssignUserID site_web_user site_web_user" - прописал как советовал umercomp "AssignUserID apache site_web_user" и немного изменил права /var/www/site_web_user.

Печально что это приходится делать в ручную, т.к. ISP Manager по умолчанию ставит другие права при добавлении конфига в vhost и получается такой косяк(или фича?)..

Только надо ли Вам это все, у Вас же панелька должна доступ иметь

Да все равно примерно такие права и стояли, разве что группа другая. На всякий случай попробовал как вы написали не помогло. Из php скрипта спокойно редактируется любой объект :(

umercomp:
а что с правами на /var/www/site_web_user?

501 site_web_user mgrsecure

А от какого по умолчанию web сервер работает, того и впишите

Работает от apache, пробовал. Не помогло. Закоментить строку "AssignUserID..." тоже пробовал, результат тот же :(

umercomp:
AssignUserID www-data site_web_user

www-data добавьте в группу site_web_user

Нет такого пользователя "www-data"..

Чтобы при обращении по IP выдавалась заглушка, а не сайт? Вписать руками заглушку в httpd.conf virtual host в самом верху. Или добавить домен любой(test.com) и перенести его в самый верх в конфиге, выше остальных хостов, тогда он будет открываться по дефолту.

negrem, в beta.webmaster.yandex.ru добавлен сайт? Если нет добавьте и посмотре, про минусинск они указывают там.

Всего: 161