Недостаточная защищённость данных на shared'е под cPanel'ю
Эта тема возникла у меня после чтения темы "Об одном способе взлома shared-вебсервера" (см. http://forum.hostobzor.ru/index.php?showtopic=4394 ) и ссылки на тему "Shared Hosting Security" в ПХП Клубе (см. http://phpclub.ru/talk/showthread.php?threadid=47772 ). А главное, после спора с моим приятелем. Спор возник как раз на тему защищённости данных. В частности лежащих в запароленных директориях. Я всегда считал - они то как раз хорошо защищены и не доступны никому! Когда мой приятель сказал мне что это не так, я поспорил с ним и проспорил таки! Он мне подсказал как довольно легко добраться к данным в запароленной директории. Но я не буду здесь его приводить чтобы не плодить хакерскую субкультуру. Все действительно знающие админы и так наверное знают его. Подскажу лишь - это с помощью крон-таблицы.
Тем кто скажет - при чём тут cPanel ? - отвечу. Именно cPanel управляет на shared'е и Cron'ом и назначением прав на директории в пользовательском аккаунте! Кто же как не она виновата в несуразных сочетаниях прав на директории и возможности доступа к директориям пользователя с помощью юникс команд?
И дискуссия в указаной теме в ПХП Клубе тоже говорит о том, что можно получить доступ к данным в чужом аккаунте на shared'е (см. http://phpclub.ru/talk/showthread.php?post...1646#post321646 ). Выходит прав и мой приятель, и господин ClayRabbit в теме на ПХП Клубе, а также выходит что прав господин Andrew Mikitenko в указанной здешней теме.
Вот ещё любопытные факты говорящие о том же. Когда cPanel создает субдомен, она помещает директорию этого субдомена в директорию public_html, не так как всегда бывало на хостингах не использующих cPanel, где субдомены создавались в директории homedir. При этом оказывается, что к субдомену есть доступ не только как subdomain.domain.ru но и как domain.ru/subdomain/ (!!!)
Это уже совсем никуда не годится! Хотя бы потому, что если в php-скриптах для субдомена используется стандартная директива определения базового пути $_SERVER['DOCUMENT_ROOT'] для подстановки его в инклуды или для иных целей, то она выдаст ложные данные при вызове страницы не как принадлежащей созданному субдомену, а вызаванной по ошибке или умышленно как подкаталог основного домена. Что означает прекращение обработки php-страницы с выдачей сообщения с путями прямо на дисплей вошедшего на страничку, вызванную таким способом. Что само по себе не есть хорошо и вполне может использоваться хакерами для очень простого способа узнать полный путь к директориям любого сайта который имеет субдомены на shared'е под cPanel'ю!
Мой приятель подсказал мне, что вроде единственный способ как-то предотвратить этот баг состоит в том, чтобы на такую директорию субдомена вручную поставить права 750 вместо 755 которые ставит автоматом cPanel.
Интересно что если взять и поставить права 750 на любую поддиректорию домена, то в броузере доступ к ней уже не получить - выдает ошибку доступа. Поэтому никак не получится хотя бы этим способом дополнительно защитить от взлома мои данные в запароленной директории, что я попробовал сделать когда узнал о недостаточной защите стандартной директивой cPanel паролирования директорий.
Короче, в парадигме создания аккаунтов в cPanel с правами похоже обстоит плохо и она создает директории которые плохо защищаны.
Выходит прав господин Andrew Mikitenko и нужно с shared'а делать ноги и подаваться на VDS если тебя заботит приватность!
Полная версия: Недостаточная защищённость данных на shared'е под cPanel'ю
Онлайн-форум hostobzor.ru > Архив (темы до 1.06.2015). Только для чтения. > Коммерческий хостинг. Общие форумы > Общие вопросы
Цитата
Выходит прав господин Andrew Mikitenko и нужно с shared'а делать ноги и подаваться на VDS если тебя заботит приватность!
Все-таки поясните. пожалуйста, для тех, кто в танке - откуда бежать
- с shared-a
- или с хостингов со стандартными панелями
- или конкретно с хостингов с cpanel
- или тем, кто конкретно хочет использовать cpanel, надо бежать на vds
Например, на хостинге с DirectAdmin структура папок другая - так там ситуация с приватностью на shared хостинге принципиально другая или нет?
Цитата(antonioni @ 10.08.2006, 14:05) 
Все-таки поясните. пожалуйста, для тех, кто в танке - откуда бежать
- с shared-a
- или с хостингов со стандартными панелями
- или конкретно с хостингов с cpanel
- или тем, кто конкретно хочет использовать cpanel, надо бежать на vds
Например, на хостинге с DirectAdmin структура папок другая - так там ситуация с приватностью на shared хостинге принципиально другая или нет?
А я что не в танке что ли? тоже как и все.
Не могу ответить на все ваши вопросы. Я не такой крутой спец, не занимаюсь провайдингом, не хостился у десятков хостеров... Но навскидку 85% их используют cPanel. Это легко видно из рекламы на сайтах, куда ходишь пока ищещь себе провайдера.
Насчет DirectAdmin не знаю, ни разу не использовал.
Вообще ваши вопросы к профи, а не к юзерам, которые могут лишь использовать то, что им предложено хостинг-провайдерами, слово "хочет" к ним то едва ли вообще применимо.
На VDS хотя бы есть выбор между предложеными провайдером средствами администрирования, уж не знаю ПОКА насколько совершенными, и прикручиванием себе на хост всего лично нужного своими собственными ручками.
Разве не так?
Вы то лично что можете сказать о проблеме, а не задавать риторических вопросов?
Цитата(Alex B @ 10.08.2006, 12:36)
Выходит прав господин Andrew Mikitenko и нужно с shared'а делать ноги и подаваться на VDS если тебя заботит приватность!
Достаточно переключить php с модуля в suexec и можно быть более защищенным.
Правами управляет не только cpanel а еще umask и их можно менять самому на более правильные.
А если нужна приватность то vds тоже мало. При взломе физического хоста можно взломать все виртуальные.
Цитата(eSupport.org.ua @ 10.08.2006, 15:21)
Достаточно переключить php с модуля в suexec и можно быть более защищенным.
Правами управляет не только cpanel а еще umask и их можно менять самому на более правильные.
А если нужна приватность то vds тоже мало. При взломе физического хоста можно взломать все виртуальные.
Нельзя ли по подробнее?
Это может делать простой юзер (тогда из чего управлять этими параметрами?)
Неужели даже из cPane'и как это можно сделать?
Видите ли в инструкциях этого вроде бы не найти...
Да, в догонку...
Неужели вы считаете обоснованно, что взлом физического хоста так же лёгок, как взлом вирутального? Тогда объяснитесь тоже...
Кстати немного подумав (хотя и не гуру) вижу, что с umask в данном случае Вы не правы.
Ведь umask установит шаблон на все юзерские директории. Если взять как я писал вначале права 750 и штамповать директории все по этому шаблону, то не будут отображаться http-доступом все поддиректории сайта.
Но именно 750 нужно бы ставить на директории субдоменов.
Это ли не прерогатива cPanel и только её?
Ведь umask установит шаблон на все юзерские директории. Если взять как я писал вначале права 750 и штамповать директории все по этому шаблону, то не будут отображаться http-доступом все поддиректории сайта.
Но именно 750 нужно бы ставить на директории субдоменов.
Это ли не прерогатива cPanel и только её?
Цитата(Alex B @ 10.08.2006, 13:36)
Мой приятель подсказал мне, что вроде единственный способ как-то предотвратить этот баг состоит в том, чтобы на такую директорию субдомена вручную поставить права 750 вместо 755 которые ставит автоматом cPanel.
Интересно что если взять и поставить права 750 на любую поддиректорию домена, то в броузере доступ к ней уже не получить - выдает ошибку доступа. Поэтому никак не получится хотя бы этим способом дополнительно защитить от взлома мои данные в запароленной директории, что я попробовал сделать когда узнал о недостаточной защите стандартной директивой cPanel паролирования директорий.
Эта проблема неактуальна у тех кто хорошо порылся с сипанели, ответ там и лежит, права на директории аккаунтов выставляет /scripts/wwwact, там легко поставить 750 и вообще как душа пожелает, а на счет того, что при таких правах папка недоступна решается патчем
Главное грамотный подход, а уж какая панель не важно. ... да ... пользуйтесь suexec
Цитата(Alex B @ 10.08.2006, 17:00)
Это может делать простой юзер (тогда из чего управлять этими параметрами?)
Неужели вы считаете обоснованно, что взлом физического хоста так же лёгок, как взлом вирутального? Тогда объяснитесь тоже...
Нет, простой юзер не может - только владелец сервера.
Взлом виртуального выделенного сервера и реального физического - идентичны, если там присутствуют одинаковые версии ПО, которые содержат уязвимости, приводящие ко взлому.
Цитата(Alex B @ 10.08.2006, 17:19)
Кстати немного подумав (хотя и не гуру) вижу, что с umask в данном случае Вы не правы.
Гуру может cPanel научить ставить права 750 user:nobody
Цитата(eSupport.org.ua @ 11.08.2006, 08:34)
Нет, простой юзер не может - только владелец сервера.
Взлом виртуального выделенного сервера и реального физического - идентичны, если там присутствуют одинаковые версии ПО, которые содержат уязвимости, приводящие ко взлому.
Гуру может cPanel научить ставить права 750 user:nobody
Вот то-то! Разве не ясно, что моя тема написана с точки зрения юзера, а не с точки зрения владельца-хостера или админа?
Бедным юзерам то что делать? От админов особенно реселлерских хостингов поддержки в таких вопросах не дождаться...
Относительно взломов физических серверов - не могу согласиться. Извините, я более верю в таких вопросах именно гуру с мировыми именами, написавших массу практичесикх руководств по защите в интернет и интранет.
Да и недаром сайты ломают как угодно и чуть не ежедневно, а взломы серверов - все же редкостью.
Цитата(HostGrad.RU @ 10.08.2006, 22:39)
Эта проблема неактуальна у тех кто хорошо порылся с сипанели, ответ там и лежит, права на директории аккаунтов выставляет /scripts/wwwact, там легко поставить 750 и вообще как душа пожелает, а на счет того, что при таких правах папка недоступна решается патчем
Главное грамотный подход, а уж какая панель не важно. ... да ... пользуйтесь suexec
Спасибо за ценные сведения! Но по существу всё это адресовано не юзерам, ьерущим хостинг, а профи - админам, ДОЛЖНЫМ настроить и Панель, и свой сервер. Где Вы видели юзера, способного проделать всё предлдоженное Вами? (А если такой есть, то едва ли он юзает шаред особенно реселлерский с их почти полной безграмотностью поддержки.)
В качестве горькой реплики: "Гуру может cPanel научить ставить права 750 user:nobody". Дык это святая обязанность производителей cPanel'и а не админов и тем более не юзеров!!! Этот факт и говорит что производители мало думают о надёжности своего товара.
Цитата(Alex B @ 11.08.2006, 10:16)
В качестве горькой реплики: "Гуру может cPanel научить ставить права 750 user:nobody". Дык это святая обязанность производителей cPanel'и а не админов и тем более не юзеров!!! Этот факт и говорит что производители мало думают о надёжности своего товара.
Продукт который ненадёжен никто использовать не будет
Дело в руках которые его используют, трудно не согласится с тем, что, на одном и том же софте и железе разные люди будут по разному им управлять и ошибки у них будут разные.
Цитата(Alex B @ 11.08.2006, 08:47)
Относительно взломов физических серверов - не могу согласиться. Извините, я более верю в таких вопросах именно гуру с мировыми именами, написавших массу практичесикх руководств по защите в интернет и интранет.
Да и недаром сайты ломают как угодно и чуть не ежедневно, а взломы серверов - все же редкостью.
Можете не верить. Я встречался с достаточным числом взломов сайтов и серверов и книжки типа "Взлом сервера за 24-е часа для чайников" не читаю
Грубо говоря - если в скрипте уязвимость - никакой защищенный сервер не поможет...
Цитата
Спасибо за ценные сведения! Но по существу всё это адресовано не юзерам, ьерущим хостинг, а профи - админам, ДОЛЖНЫМ настроить и Панель, и свой сервер. Где Вы видели юзера, способного проделать всё предлдоженное Вами? (А если такой есть, то едва ли он юзает шаред особенно реселлерский с их почти полной безграмотностью поддержки.)
Именно об этом я и говорю. Это не пользовательское дело - сервера настраивать. Пользователь может взять vds и заказать настройку у админа - тогда он будет хоть как-то защищен.
Цитата(Alex B @ 11.08.2006, 09:16)
В качестве горькой реплики: "Гуру может cPanel научить ставить права 750 user:nobody". Дык это святая обязанность производителей cPanel'и а не админов и тем более не юзеров!!! Этот факт и говорит что производители мало думают о надёжности своего товара.
cPanel - это топор. Им можно дрова нарубить а можно и палец оттяпаять.
Все зависит от рук, в которые попал топор.
P.S. Можете попробовать подать на cPanel в суд за ненадежность.
Цитата(eSupport.org.ua @ 11.08.2006, 11:50)
Можете не верить. Я встречался с достаточным числом взломов сайтов и серверов и книжки типа "Взлом сервера за 24-е часа для чайников" не читаю
Ну зачем же так передёргивать?! 24-часовые курсы изучения чего бы то ни было и я не читал и не читаю.
К тому же Вы не держите контекста в теме. Я же ведь говорил изначально и на протяжении темы о ВИРТУАЛЬНОМ ХОСТИНГЕ, след-но о разделении ресурсов Apache. Если же я вынужденно сравнивал устойчивость шареда с большей устойчивостью VDS - это означает сравнение не физического и вирутального сервера (т.е. суть ОС), а любого сервера на котором есть один неразделяемый ни с кем Apache, и напротив - разделяемый между многиими клиентам на шареде. И ежу понятно что второй шаред-вариант менее устойчив. Против этого кажется ни в одной из тем здесь никто не возражал никогда.
Цитата(eSupport.org.ua @ 11.08.2006, 11:50)
Грубо говоря - если в скрипте уязвимость - никакой защищенный сервер не поможет...
Именно об этом я и говорю. Это не пользовательское дело - сервера настраивать. Пользователь может взять vds и заказать настройку у админа - тогда он будет хоть как-то защищен.
И я о том же говорил! Именно так, если VDS да хороший админ хорошего провайдера то с защищенностью будет всё ОК!
Цитата(eSupport.org.ua @ 11.08.2006, 11:50)
cPanel - это топор. Им можно дрова нарубить а можно и палец оттяпаять.
Все зависит от рук, в которые попал топор.
P.S. Можете попробовать подать на cPanel в суд за ненадежность.
Инструмент инструменту рознь. Если с топорища постянно слетает топор, то оттяпать можно и ногу, и даже голову - если не повезёт случайному прохожему
Что касется рук - полность с Вами согласен. Вот я и вижу всё более и более, что те руки делавшие такие товары как cPanel не слишком умелые и профессиональные... хотя приложеные головы к тем рукам очень сильно заботятся о cool-популярности у юзеров известного уровня и менталитета...
Относительно совета подать в суд на фирму - спасибо! Если бы я жил в сша, то наверно был бы шанс это сделать не без пользы...
хотя лично у меня значимого ущерба не случилсь так что даже формального повода нет.Спасибо людям и этому интернт-реусурсу что надоумили своевременно обратить внимание на вопросы безопасности.
Цитата(Alex B @ 11.08.2006, 11:27)
Что касется рук - полность с Вами согласен. Вот я и вижу всё более и более, что те руки делавшие такие товары как cPanel не слишком умелые и профессиональные... хотя приложеные головы к тем рукам очень сильно заботятся о cool-популярности у юзеров известного уровня и менталитета...
Добавьте к не слишком еще DirectAdmin и Plesk - там есть аналогичные проблемы.
Цитата(Alex B @ 11.08.2006, 10:16)
В качестве горькой реплики: "Гуру может cPanel научить ставить права 750 user:nobody". Дык это святая обязанность производителей cPanel'и а не админов и тем более не юзеров!!! Этот факт и говорит что производители мало думают о надёжности своего товара.
Как говорится больного на операционный стол /scripts/wwwacct (скрипт создание аккаунта)
Код
#!/usr/bin/perl
...
...
...
if ( exists $cpconf{'acls'} && $cpconf{'acls'} eq '1') {
if (my $pid = fork()) {
waitpid($pid,0);
} else {
setuids($user);
system('setfacl','-kb','-m','group:nobody:x',
'-m','group:mail:x',
'-m','group:cpanel:x',
'-m','group:mailnull:x',
'-m','group:65535:x',
'-m','group:ftp:x',
'--',"$mnt/$user");
chmod(0750,"$mnt/$user");
exit;
}
} else {
cPScript::SafetyBits::safe_chmod(0711,$mmuid,"$mnt/$user");
}
if (-e '/var/cpanel/fileprotect') {
my $httpgid = (getgrnam('nobody'))[2];
cPScript::SafetyBits::safe_userchgid($mmuid,$httpgid,"$mnt/$user/public_html");
cPScript::SafetyBits::safe_chmod(0750,$mmuid,"$mnt/$user/public_html");
}
...
...
...
if ( exists $cpconf{'acls'} && $cpconf{'acls'} eq '1') {
if (my $pid = fork()) {
waitpid($pid,0);
} else {
setuids($user);
system('setfacl','-kb','-m','group:nobody:x',
'-m','group:mail:x',
'-m','group:cpanel:x',
'-m','group:mailnull:x',
'-m','group:65535:x',
'-m','group:ftp:x',
'--',"$mnt/$user");
chmod(0750,"$mnt/$user");
exit;
}
} else {
cPScript::SafetyBits::safe_chmod(0711,$mmuid,"$mnt/$user");
}
if (-e '/var/cpanel/fileprotect') {
my $httpgid = (getgrnam('nobody'))[2];
cPScript::SafetyBits::safe_userchgid($mmuid,$httpgid,"$mnt/$user/public_html");
cPScript::SafetyBits::safe_chmod(0750,$mmuid,"$mnt/$user/public_html");
}
как видно разработчики всёже озаботились такой насущьной проблемой как права на папки
типа 750 и nobody и для настройки ихнего детища вродебы и не надо никаких плясок с бубном типа переписывания скриптов
а для тех чьи желания они не учли здесь у них имеется автоматический скрипт
/scripts/postwwwacct и /scripts/postwwwacct куда можно писать что угодно
Я не думаю что разработчики панелей глупые люди и неучитывают аспектов безопасности,
а вот на неквалифицированных хостеров бочку и надо катить тем пользователям которрые страдают по вине недонастройки и неправильной настройки серверов.
в спанели это действительно большой недостаток - класть поддомены в public_html это сугубо неправильно и совершенно нелогично по жизни. Виртуальные то хосты в любом случае создаются, чтобы не сделать нормальный вебрут и докрут. Но, что сделано то сделано. Это не единственная проблема спанели, но одна из тех которые просто наиболее бросаются в глаза.
Что касается крона к примеру, а нет пока альтернативы - либо разрешать их, либо не разрешать. Вот недавно столкнулся с хостингом на директи - у них он просто запрещен. Можно только шедулер использовать а он только по урлам работает (через http://). Надежно? Да, вполне. Но вот приладить клиенту то что он просил не получилось из за этого. Любое решение - это компромисс между надежностью и функциональностью. Как только вы размещаете на сервере второго юзера вы уже теряете в секурности Вопрос в оптимальном соотношении цены - функциональности - устойчивости - безопасности.
Скажем мы всем говорим - ставьте 400 права на конфиги своих скриптов и будет вам счастье. Прочесть сможет только сам юзер. И все равно у нас сайты ломают. Форумы/Порталы - закачивают r57shell с void.ru как картинку или как аватар. Файл естественно с правами юзера. Далее достаточно пройти на файл и шелл на аккаунте у вас в кармане. Правда максимум что в результате получается это подгадить базам да потереть файлы, но тем не менее. Для кого то ведь нагадить другому это самое то...
Что касается крона к примеру, а нет пока альтернативы - либо разрешать их, либо не разрешать. Вот недавно столкнулся с хостингом на директи - у них он просто запрещен. Можно только шедулер использовать а он только по урлам работает (через http://). Надежно? Да, вполне. Но вот приладить клиенту то что он просил не получилось из за этого. Любое решение - это компромисс между надежностью и функциональностью. Как только вы размещаете на сервере второго юзера вы уже теряете в секурности
Вопрос в оптимальном соотношении цены - функциональности - устойчивости - безопасности.Скажем мы всем говорим - ставьте 400 права на конфиги своих скриптов и будет вам счастье. Прочесть сможет только сам юзер. И все равно у нас сайты ломают. Форумы/Порталы - закачивают r57shell с void.ru как картинку или как аватар. Файл естественно с правами юзера. Далее достаточно пройти на файл и шелл на аккаунте у вас в кармане. Правда максимум что в результате получается это подгадить базам да потереть файлы, но тем не менее. Для кого то ведь нагадить другому это самое то...
Цитата(rustelekom @ 12.08.2006, 01:52)
Форумы/Порталы - закачивают r57shell с void.ru как картинку или как аватар. Файл естественно с правами юзера. Далее достаточно пройти на файл и шелл на аккаунте у вас в кармане. Правда максимум что в результате получается это подгадить базам да потереть файлы, но тем не менее. Для кого то ведь нагадить другому это самое то...
Я помню когда то давно выкладывал скрипт, который находит записывыемые upload директории и ставит туда .htaccess отключающий испонение скриптов.
От r57shell помогает.
Цитата(eSupport.org.ua @ 11.08.2006, 13:47)
Добавьте к не слишком еще DirectAdmin и Plesk - там есть аналогичные проблемы.
Неужто и в этих Панелях права на директории субдоменов ставятся неправильно? Я писал что не знаю никаких панелей кроме cPanel и что я - пользователь а не админ. Тем не менее хотелось бы уже до самого конца разобраться в этом вопросе с помощью тех кто юзает разные панели. Может быть всё таки удастся разрешить эти проблемы с помощью общественного обсуждения...
Цитата(cobain @ 12.08.2006, 02:18)
....
как видно разработчики всёже озаботились такой насущьной проблемой как права на папки
типа 750 и nobody и для настройки ихнего детища вродебы и не надо никаких плясок с бубном типа переписывания скриптов
а для тех чьи желания они не учли здесь у них имеется автоматический скрипт
/scripts/postwwwacct и /scripts/postwwwacct куда можно писать что угодно
Я не думаю что разработчики панелей глупые люди и неучитывают аспектов безопасности,
а вот на неквалифицированных хостеров бочку и надо катить тем пользователям которрые страдают по вине недонастройки и неправильной настройки серверов.
Спасибо за столь подробное информирование общественности.
Я не админ и мне трудно вникать в столь глубокие тоноксти системы тем более на перле, но я вижу что там где нужно вроде бы их скрипты ставят 750. Так как же может получаться - как Вы пишете, виноваты кривые админские ручки? Неужто админы будут как-то подправлять эти скрипты cPanel'и или делать что-то еще более непотребное? Это мне осталось всё равно непонятным и после публикования этого постинга. Извиняйте за тупость.
Цитата(rustelekom @ 12.08.2006, 02:52)
в спанели это действительно большой недостаток - класть поддомены в public_html это сугубо неправильно и совершенно нелогично по жизни. Виртуальные то хосты в любом случае создаются, чтобы не сделать нормальный вебрут и докрут. Но, что сделано то сделано. Это не единственная проблема спанели, но одна из тех которые просто наиболее бросаются в глаза.
Что касается крона к примеру, а нет пока альтернативы - либо разрешать их, либо не разрешать. Вот недавно столкнулся с хостингом на директи - у них он просто запрещен. Можно только шедулер использовать а он только по урлам работает (через http://). Надежно? Да, вполне. Но вот приладить клиенту то что он просил не получилось из за этого. Любое решение - это компромисс между надежностью и функциональностью. Как только вы размещаете на сервере второго юзера вы уже теряете в секурности
Вопрос в оптимальном соотношении цены - функциональности - устойчивости - безопасности.Скажем мы всем говорим - ставьте 400 права на конфиги своих скриптов и будет вам счастье. Прочесть сможет только сам юзер. И все равно у нас сайты ломают. Форумы/Порталы - закачивают r57shell с void.ru как картинку или как аватар. Файл естественно с правами юзера. Далее достаточно пройти на файл и шелл на аккаунте у вас в кармане. Правда максимум что в результате получается это подгадить базам да потереть файлы, но тем не менее. Для кого то ведь нагадить другому это самое то...
Выскажусь здесь только по крону: что знаю, то знаю, а остальное - админские тонкости...
Даже мне представляется вполне простым сделать при вызове крон-таблицы проверки на допустимый список команд. Не думаю что это столь неразрешимая или ресурсоёмкая задачка...
Реплика. Вы писали: "Форумы/Порталы - закачивают r57shell с void.ru как картинку или как аватар. Файл естественно с правами юзера. Далее достаточно пройти на файл и шелл на аккаунте у вас в кармане. Правда максимум что в результате получается это подгадить базам да потереть файлы, но тем не менее" - это похоже именно первый шаг что был сделан хакерами в отношении взлома описанного в постинге http://forum.hostobzor.ru/index.php?showtopic=4394 !!! ИМХО...
Цитата(eSupport.org.ua @ 12.08.2006, 07:49)
Я помню когда то давно выкладывал скрипт, который находит записывыемые upload директории и ставит туда .htaccess отключающий испонение скриптов.
От r57shell помогает.
Этот скрипт и такую практику надо бы сдалать достоянием интернет-общественности и нормальной практикой хостинг-провайдеров...
ДОБАВЛЕНИЕ (для cobain)
Может быть тут дело в том что у меня хостер юзает еще версию cPanel 10.8.1-RELEASE 113 ?
Может она устарела и там нет правильно выставленных прав на эти директории? - извиняйте, я простой юзер.
Может быть тут дело в том что у меня хостер юзает еще версию cPanel 10.8.1-RELEASE 113 ?
Может она устарела и там нет правильно выставленных прав на эти директории? - извиняйте, я простой юзер.
Цитата(Alex B @ 12.08.2006, 13:16)
Неужто и в этих Панелях права на директории субдоменов ставятся неправильно?
Они априори неправильно ставяться там где работает mod_php с правами nobody. Если права стоят user:nobody, то сайт можно сломать изнутри, купив хостинг на этом сервере.
Цитата
Я не админ и мне трудно вникать в столь глубокие тоноксти системы тем более на перле, но я вижу что там где нужно вроде бы их скрипты ставят 750. Так как же может получаться - как Вы пишете, виноваты кривые админские ручки? Неужто админы будут как-то подправлять эти скрипты cPanel'и или делать что-то еще более непотребное? Это мне осталось всё равно непонятным и после публикования этого постинга. Извиняйте за тупость.
750 - это мало. Не дает полной надежности. Только 700/600. В случае взлома сайтов в 70% виноваты руки админов и в 30% - руки скриптовписателей.
Подправлять скрипты ненадо - достаточно отключить вредные функции.
Цитата
Выскажусь здесь только по крону: что знаю, то знаю, а остальное - админские тонкости...
Даже мне представляется вполне простым сделать при вызове крон-таблицы проверки на допустимый список команд. Не думаю что это столь неразрешимая или ресурсоёмкая задачка...
Сделайте. Реализацию скиньте - интересно.
Цитата
Реплика. Вы писали: "Форумы/Порталы - закачивают r57shell с void.ru как картинку или как аватар. Файл естественно с правами юзера. Далее достаточно пройти на файл и шелл на аккаунте у вас в кармане. Правда максимум что в результате получается это подгадить базам да потереть файлы, но тем не менее" - это похоже именно первый шаг что был сделан хакерами в отношении взлома описанного в постинге http://forum.hostobzor.ru/index.php?showtopic=4394 !!! ИМХО...
Именно так и делают взломы форумов. В этом виноваты и владельцы и авторы и хостеры
Для eSupport.org.ua:
1. По всей видимости Вы говорите о правах на директорию public_html а не на директори субдоменов которые создаются cPanel'ю уже после самими юзерами - если им это необходимо. См. также мой постинг - дополнение2 для cobain.
2. Не могли бы Вы по подробнее изложить, как нужно ставить права на эти две категории директорий в двух случаях: а) работает mod_php и б) работает suexec.
3. Ваше фраза "Если права стоят user:nobody, то сайт можно сломать изнутри, купив хостинг на этом сервере" без того что я прошу объяснить в п.2 мне осталась не понятной. (Я же не админ.)
4. Я понимаю что только 700/600 лишь вполне обеспечат безопасность. Но ведь это действительно можно сделать лишь если Апача исполняет хттп-вызовы с правами юзера этого акаунта? Много ли шаредов где это реализовано? навскидку - нет, немного... экономят на спичках!
5. Относительно крона. Вы мне предлагаете сделать реализацию... хм, разве я позиционировал себя как гуру *никс? или как хотя бы администратора серверов? Этим и сходным категориям профи действительно несложно:
а) получить исходняки
б) разобраться во всех тонкостях фунциклирования утилиты
в) связаться с гуру *никс мира если что-то непонятно
г) в случае удачи реализации своей задумки опубликовть её так и там где она получит всеобщую известность и т.п.
Я же простой юзер с кругом занятий связанных с прикладным программированием и использую интернет - хостинг именно в этих целях. И поэтому то что тем людям займет полдня - мне раелизовать придется с упорным исследованием и сбором сведений на протяжении многих многих дней. Увольте!
Сам же идея тривиальна. а) контроль того что юзер/хакер подсунул в кронтаблицу б) отбрасывание всего что запрещено в конфирурационном ф-ле (навскидку на шареде можно разрешить через крон запускать пхп и перл скриты и только!!!)
Ясно же должно быть каждому что в такой агрессивной среде нужно использовать усиленные меры безопасности - большие чем обычны в ОС класса *никс юзаемые в том же интарнете (не интернете)!
6. Вот Вы утверждаете: "В этом виноваты и владельцы и авторы и хостеры" - не могу в данном контексте согласиться в первой позицией... она из известного разряда "отмазок". Если есть хакерский r57shell безусловно известный хостерам - админам и спецам тенм же писателям софта для хостингов, и до сих пор нету заплат для защиты от него на уровне сервера (что прерогатива как минимум админов хостингов) - это явно наплевательское отношение к потребителям услуг.
Юзера не обязаны дополнительно защищать свои аккаунты от взломов. Покупая хостинг всякий предполагает что если он использует предустановленные услуги конфигурации и данные му сервисы - он делате всё правильно и он защищён!
7. Вы писали (правда в теме "DirectAdmin или cPanel?" - отвечаю заодно ): "Мало опыта значит у Вас" - я и не позиционировал себя как гуру, напротив как простой юзер. А вот Ваше: "А делается это элементарно, на уровне - каждому юзеру по апачу" - это же явно относится и значимо как минимум для админа.
Странная это позиция при форумной переписке - советовать юзеру то что он не может сделать на шареде.
******************
Как говорится больного на операционный стол /scripts/wwwacct (скрипт создание аккаунта)
...
ДОБАВЛЕНИЕ2 (для cobain)
Сегодня я расследовал в чем тут дело. Хотя у меня нет доступа к кодам, как у вас, но я понял что этот участок кода отвечает за создание корневой директории сайта public_html а никак не директорий субдоменов!
Вот public_html действительно всегда имеет права 750 (проверил на двух хостингах с cPanel'ю).
Уж не знаю исходя из каких соображений - Вам лично это известно - Вы публиковали этот код... то ли выбран он был по причине невнимательного прочтения темы то ли были иные соображения. Ясно одно - он не имеет отношения к существу темы. А субдоменские директории делает какой-то иной участок кода cPanel'и...
1. По всей видимости Вы говорите о правах на директорию public_html а не на директори субдоменов которые создаются cPanel'ю уже после самими юзерами - если им это необходимо. См. также мой постинг - дополнение2 для cobain.
2. Не могли бы Вы по подробнее изложить, как нужно ставить права на эти две категории директорий в двух случаях: а) работает mod_php и б) работает suexec.
3. Ваше фраза "Если права стоят user:nobody, то сайт можно сломать изнутри, купив хостинг на этом сервере" без того что я прошу объяснить в п.2 мне осталась не понятной. (Я же не админ.)
4. Я понимаю что только 700/600 лишь вполне обеспечат безопасность. Но ведь это действительно можно сделать лишь если Апача исполняет хттп-вызовы с правами юзера этого акаунта? Много ли шаредов где это реализовано? навскидку - нет, немного... экономят на спичках!
5. Относительно крона. Вы мне предлагаете сделать реализацию... хм, разве я позиционировал себя как гуру *никс? или как хотя бы администратора серверов? Этим и сходным категориям профи действительно несложно:
а) получить исходняки
б) разобраться во всех тонкостях фунциклирования утилиты
в) связаться с гуру *никс мира если что-то непонятно
г) в случае удачи реализации своей задумки опубликовть её так и там где она получит всеобщую известность и т.п.
Я же простой юзер с кругом занятий связанных с прикладным программированием и использую интернет - хостинг именно в этих целях. И поэтому то что тем людям займет полдня - мне раелизовать придется с упорным исследованием и сбором сведений на протяжении многих многих дней. Увольте!
Сам же идея тривиальна. а) контроль того что юзер/хакер подсунул в кронтаблицу б) отбрасывание всего что запрещено в конфирурационном ф-ле (навскидку на шареде можно разрешить через крон запускать пхп и перл скриты и только!!!)
Ясно же должно быть каждому что в такой агрессивной среде нужно использовать усиленные меры безопасности - большие чем обычны в ОС класса *никс юзаемые в том же интарнете (не интернете)!
6. Вот Вы утверждаете: "В этом виноваты и владельцы и авторы и хостеры
" - не могу в данном контексте согласиться в первой позицией... она из известного разряда "отмазок". Если есть хакерский r57shell безусловно известный хостерам - админам и спецам тенм же писателям софта для хостингов, и до сих пор нету заплат для защиты от него на уровне сервера (что прерогатива как минимум админов хостингов) - это явно наплевательское отношение к потребителям услуг.Юзера не обязаны дополнительно защищать свои аккаунты от взломов. Покупая хостинг всякий предполагает что если он использует предустановленные услуги конфигурации и данные му сервисы - он делате всё правильно и он защищён!
7. Вы писали (правда в теме "DirectAdmin или cPanel?" - отвечаю заодно
): "Мало опыта значит у Вас" - я и не позиционировал себя как гуру, напротив как простой юзер. А вот Ваше: "А делается это элементарно, на уровне - каждому юзеру по апачу" - это же явно относится и значимо как минимум для админа.Странная это позиция при форумной переписке - советовать юзеру то что он не может сделать на шареде.
******************
Цитата(cobain @ 12.08.2006, 02:18)
Как говорится больного на операционный стол /scripts/wwwacct (скрипт создание аккаунта)
...
ДОБАВЛЕНИЕ2 (для cobain)
Сегодня я расследовал в чем тут дело. Хотя у меня нет доступа к кодам, как у вас, но я понял что этот участок кода отвечает за создание корневой директории сайта public_html а никак не директорий субдоменов!
Вот public_html действительно всегда имеет права 750 (проверил на двух хостингах с cPanel'ю).
Уж не знаю исходя из каких соображений - Вам лично это известно - Вы публиковали этот код... то ли выбран он был по причине невнимательного прочтения темы то ли были иные соображения. Ясно одно - он не имеет отношения к существу темы. А субдоменские директории делает какой-то иной участок кода cPanel'и...
[quote]
1. По всей видимости Вы говорите о правах на директорию public_html а не на директори субдоменов которые создаются cPanel'ю уже после самими юзерами - если им это необходимо. См. также мой постинг - дополнение2 для cobain.
[/quote]
Это не принципиально с какими правами они создаются - 750 или 755. Гарантию может дать только 600.
[quote]
2. Не могли бы Вы по подробнее изложить, как нужно ставить права на эти две категории директорий в двух случаях: а) работает mod_php и б) работает suexec.
[/quote]
На mod_php минимальные права 750/640 user:apache, на suexec/cgi 750 user:user
[quote]
3. Ваше фраза "Если права стоят user:nobody, то сайт можно сломать изнутри, купив хостинг на этом сервере" без того что я прошу объяснить в п.2 мне осталась не понятной. (Я же не админ.)
[/quote]
Я не буду объяснять как взламывают сайты, извините.
[quote]
4. Я понимаю что только 700/600 лишь вполне обеспечат безопасность. Но ведь это действительно можно сделать лишь если Апача исполняет хттп-вызовы с правами юзера этого акаунта? Много ли шаредов где это реализовано? навскидку - нет, немного... экономят на спичках!
[/quote]
Вы бы согласились платить за хостинг с такими правами начиная от 30$/мес, в то время как VDS можно взять от 5$/мес?
[quote]
5. Относительно крона. Вы мне предлагаете сделать реализацию... хм, разве я позиционировал себя как гуру *никс? или как хотя бы администратора серверов?
[/quote]
Тогда не стоит говорить о тех вещах, в которых Вы не разбираетесь. Ибо изменять исходники одного крона недостаточно - придется перелопатить всю систему.
[quote]
Сам же идея тривиальна. а) контроль того что юзер/хакер подсунул в кронтаблицу б) отбрасывание всего что запрещено в конфирурационном ф-ле (навскидку на шареде можно разрешить через крон запускать пхп и перл скриты и только!!!)
[/quote]
Извините. Но Вы абсолютно не разбираетесь в UNIX. Ибо я в своем perl/php скрипте могу запускать любые процессы с любыми командами.
[quote]
Ясно же должно быть каждому что в такой агрессивной среде нужно использовать усиленные меры безопасности - большие чем обычны в ОС класса *никс юзаемые в том же интарнете (не интернете)!
[/quote]
Эта мера известна давно. И называется она - VDS
[quote]
6. Вот Вы утверждаете: "В этом виноваты и владельцы и авторы и хостеры" - не могу в данном контексте согласиться в первой позицией... она из известного разряда "отмазок". Если есть хакерский r57shell безусловно известный хостерам - админам и спецам тенм же писателям софта для хостингов, и до сих пор нету заплат для защиты от него на уровне сервера (что прерогатива как минимум админов хостингов) - это явно наплевательское отношение к потребителям услуг.
Юзера не обязаны дополнительно защищать свои аккаунты от взломов. Покупая хостинг всякий предполагает что если он использует предустановленные услуги конфигурации и данные му сервисы - он делате всё правильно и он защищён!
[/quote]
Если владелец ставит сам 777 права на директорию - виноват только владелец. Это не отмазка, это - факт
Защита от r57shell есть - исключается выход за пределы homedir, куда он закачен.
Юзеры не обязаны дополнительно защищаться сами. Тогда их ломают
Впрочем, я знаю сервера которые нельзя сломать через такой скрипт. narod.ru например
Еще раз повторюсь - если нужна безопасность - берите VDS и заказывайте его security.
7. Вы писали (правда в теме "DirectAdmin или cPanel?" - отвечаю заодно ): "Мало опыта значит у Вас" - я и не позиционировал себя как гуру, напротив как простой юзер. А вот Ваше: "А делается это элементарно, на уровне - каждому юзеру по апачу" - это же явно относится и значимо как минимум для админа.
Странная это позиция при форумной переписке - советовать юзеру то что он не может сделать на шареде.
******************
ДОБАВЛЕНИЕ2 (для cobain)
Сегодня я расследовал в чем тут дело. Хотя у меня нет доступа к кодам, как у вас, но я понял что этот участок кода отвечает за создание корневой директории сайта public_html а никак не директорий субдоменов!
Вот public_html действительно всегда имеет права 750 (проверил на двух хостингах с cPanel'ю).
Уж не знаю исходя из каких соображений - Вам лично это известно - Вы публиковали этот код... то ли выбран он был по причине невнимательного прочтения темы то ли были иные соображения. Ясно одно - он не имеет отношения к существу темы. А субдоменские директории делает какой-то иной участок кода cPanel'и...
[/quote]
1. По всей видимости Вы говорите о правах на директорию public_html а не на директори субдоменов которые создаются cPanel'ю уже после самими юзерами - если им это необходимо. См. также мой постинг - дополнение2 для cobain.
[/quote]
Это не принципиально с какими правами они создаются - 750 или 755. Гарантию может дать только 600.
[quote]
2. Не могли бы Вы по подробнее изложить, как нужно ставить права на эти две категории директорий в двух случаях: а) работает mod_php и б) работает suexec.
[/quote]
На mod_php минимальные права 750/640 user:apache, на suexec/cgi 750 user:user
[quote]
3. Ваше фраза "Если права стоят user:nobody, то сайт можно сломать изнутри, купив хостинг на этом сервере" без того что я прошу объяснить в п.2 мне осталась не понятной. (Я же не админ.)
[/quote]
Я не буду объяснять как взламывают сайты, извините.
[quote]
4. Я понимаю что только 700/600 лишь вполне обеспечат безопасность. Но ведь это действительно можно сделать лишь если Апача исполняет хттп-вызовы с правами юзера этого акаунта? Много ли шаредов где это реализовано? навскидку - нет, немного... экономят на спичках!
[/quote]
Вы бы согласились платить за хостинг с такими правами начиная от 30$/мес, в то время как VDS можно взять от 5$/мес?
[quote]
5. Относительно крона. Вы мне предлагаете сделать реализацию... хм, разве я позиционировал себя как гуру *никс? или как хотя бы администратора серверов?
[/quote]
Тогда не стоит говорить о тех вещах, в которых Вы не разбираетесь. Ибо изменять исходники одного крона недостаточно - придется перелопатить всю систему.
[quote]
Сам же идея тривиальна. а) контроль того что юзер/хакер подсунул в кронтаблицу б) отбрасывание всего что запрещено в конфирурационном ф-ле (навскидку на шареде можно разрешить через крон запускать пхп и перл скриты и только!!!)
[/quote]
Извините. Но Вы абсолютно не разбираетесь в UNIX. Ибо я в своем perl/php скрипте могу запускать любые процессы с любыми командами.
[quote]
Ясно же должно быть каждому что в такой агрессивной среде нужно использовать усиленные меры безопасности - большие чем обычны в ОС класса *никс юзаемые в том же интарнете (не интернете)!
[/quote]
Эта мера известна давно. И называется она - VDS
[quote]
6. Вот Вы утверждаете: "В этом виноваты и владельцы и авторы и хостеры
" - не могу в данном контексте согласиться в первой позицией... она из известного разряда "отмазок". Если есть хакерский r57shell безусловно известный хостерам - админам и спецам тенм же писателям софта для хостингов, и до сих пор нету заплат для защиты от него на уровне сервера (что прерогатива как минимум админов хостингов) - это явно наплевательское отношение к потребителям услуг.Юзера не обязаны дополнительно защищать свои аккаунты от взломов. Покупая хостинг всякий предполагает что если он использует предустановленные услуги конфигурации и данные му сервисы - он делате всё правильно и он защищён!
[/quote]
Если владелец ставит сам 777 права на директорию - виноват только владелец. Это не отмазка, это - факт
Защита от r57shell есть - исключается выход за пределы homedir, куда он закачен.
Юзеры не обязаны дополнительно защищаться сами. Тогда их ломают
Впрочем, я знаю сервера которые нельзя сломать через такой скрипт. narod.ru например
Еще раз повторюсь - если нужна безопасность - берите VDS и заказывайте его security.
7. Вы писали (правда в теме "DirectAdmin или cPanel?" - отвечаю заодно
): "Мало опыта значит у Вас" - я и не позиционировал себя как гуру, напротив как простой юзер. А вот Ваше: "А делается это элементарно, на уровне - каждому юзеру по апачу" - это же явно относится и значимо как минимум для админа.Странная это позиция при форумной переписке - советовать юзеру то что он не может сделать на шареде.
******************
ДОБАВЛЕНИЕ2 (для cobain)
Сегодня я расследовал в чем тут дело. Хотя у меня нет доступа к кодам, как у вас, но я понял что этот участок кода отвечает за создание корневой директории сайта public_html а никак не директорий субдоменов!
Вот public_html действительно всегда имеет права 750 (проверил на двух хостингах с cPanel'ю).
Уж не знаю исходя из каких соображений - Вам лично это известно - Вы публиковали этот код... то ли выбран он был по причине невнимательного прочтения темы то ли были иные соображения. Ясно одно - он не имеет отношения к существу темы. А субдоменские директории делает какой-то иной участок кода cPanel'и...
[/quote]
ПОПРАВКА: сам себя поправляю в п.5 - в том алгоритме защиты крона нужно действовать не из принципа "разрешено всё что явно не запрещено", а из принципа "выполняется лишь то что явно разрешено, остальное директивно запрещено" !!!
Цитата(eSupport.org.ua @ 13.08.2006, 12:06)
Это не принципиально с какими правами они создаются - 750 или 755. Гарантию может дать только 600.
На mod_php минимальные права 750/640 user:apache, на suexec/cgi 750 user:user
Спасибо за сведения.
Цитата(eSupport.org.ua @ 13.08.2006, 12:06)
Вы бы согласились платить за хостинг с такими правами начиная от 30$/мес, в то время как VDS можно взять от 5$/мес?
Странное ценообразование (правдя это с Ваших слов, в реалии я такого не видел)!
Если на VDS делится между клиентами аж вся ОС, а тут лишь Апача, то это очень странно...
Цитата(eSupport.org.ua @ 13.08.2006, 12:06)
Тогда не стоит говорить о тех вещах, в которых Вы не разбираетесь. Ибо изменять исходники одного крона недостаточно - придется перелопатить всю систему.
Вот те здрасте пожалуйста! С каких это пор чтобы отпарсить в утилите входную строчку на НЕ допустимые занчения параметров нужно перелопачивать всю ОС!???
К тому же есть паллеатив. хотя более слабый в степени защиты: использвать парсилку прямо в Панели. Но тогда не будет защиты от вставки в кронтаблу чего-то непотребного иными хакерскими срадствами...
Не спешите обвинять других, лучше подумайте сначал непредвзято своим умом...
Цитата(eSupport.org.ua @ 13.08.2006, 12:06)
Извините. Но Вы абсолютно не разбираетесь в UNIX. Ибо я в своем perl/php скрипте могу запускать любые процессы с любыми командами.
Аналогично вышенаписанному. Неужто трудно сообразить что если на хосте в скриптах разрешено испольнять ВСЁ, то на шареде о защите вообще следует забыть!
Нужно же понимать что при любой нормальной настройке сервера из правильно сконфигрурированных языков не исполнить тот же вызов чтения/записи применительно к данным из чужой директории, а лишь разрешено это применительно к своей!
Крон же по всей видимости "забыли" защитить должным образом...
Цитата(eSupport.org.ua @ 13.08.2006, 12:06)
Эта мера известна давно. И называется она - VDS
Хе-хе! Прочтите строчку из моего топика. Для простоты привожу её здесь снова: "...нужно с shared'а делать ноги и подаваться на VDS если тебя заботит приватность!" Вы мне не открыли америк.
Цитата(eSupport.org.ua @ 13.08.2006, 12:06)
Если владелец ставит сам 777 права на директорию - виноват только владелец. Это не отмазка, это - факт
А причем здесь это? Если юзер вообще всё и для всех откроет у себя - это проблемы того юзера. В данной теме я чётко обозначил проблему и даже дал её решение "вручную". Зачем же так утрировать и передергивать то?
Цитата(eSupport.org.ua @ 13.08.2006, 12:06)
Защита от r57shell есть - исключается выход за пределы homedir, куда он закачен.
Именно! Но сделать это могут админы и/или писатели административных скриптов!
О том я и говорю уже несколько дней этой темой.
Цитата(eSupport.org.ua @ 13.08.2006, 12:06)
Юзеры не обязаны дополнительно защищаться сами. Тогда их ломают
Вот-вот!... понимали бы это еще инстанции предоставляющие хостинг
Цитата(eSupport.org.ua @ 13.08.2006, 12:06)
Впрочем, я знаю сервера которые нельзя сломать через такой скрипт. narod.ru например
Полагаю что это от того что там запрещено всё что абсолютно не есть необходимо на хосте. Последнее - из перечня услуг этого бесплатного шареда...
Для непонятливых профи и чтобы не посчитали меня голословным в предложении дозащиты крона приведу костяк алгоритма - в псевдокоде, извиняйте, даже на русском - лень присать _настоящий_ код за профи на халяву
Скажем утилита названная netcron изменённая под нужды интернет-хостинга должна проверять входную строчку $ins так:
1. разделяем $ins на компоненты массива: 1-й всегда сама команда, 2-й (и возможно последующие) - параметры команды.
2. сначала проверяем саму команду на принадлежность к списку из netcron.ini (скажем содержит строку: "perl php" - т.е. они только и разрешены) - если команда не принадлежит к списку разрешенных, то переход к п.5.
3. затем находим в массиве параметров команды путь к скрипту (скажем по наличию слешей всегда имеющихся в пути) который должна исполнить эта команда.
4. проверям путь: если он ПРИНАДЕЖИТ домашней директории данного юзера, от лица которого крон исполняет крон-таблицу, значит всё ОК - переход на код выполнения стандартного крона (п.7).
5. нет - записываем всю входную строчку и логин юзера в ф-л лога безопасности - на предмет информирования админа о попытках взлома.
6. аборт!
7. исполнение стандартного крон-кода.
Скажем утилита названная netcron изменённая под нужды интернет-хостинга должна проверять входную строчку $ins так:
1. разделяем $ins на компоненты массива: 1-й всегда сама команда, 2-й (и возможно последующие) - параметры команды.
2. сначала проверяем саму команду на принадлежность к списку из netcron.ini (скажем содержит строку: "perl php" - т.е. они только и разрешены) - если команда не принадлежит к списку разрешенных, то переход к п.5.
3. затем находим в массиве параметров команды путь к скрипту (скажем по наличию слешей всегда имеющихся в пути) который должна исполнить эта команда.
4. проверям путь: если он ПРИНАДЕЖИТ домашней директории данного юзера, от лица которого крон исполняет крон-таблицу, значит всё ОК - переход на код выполнения стандартного крона (п.7).
5. нет - записываем всю входную строчку и логин юзера в ф-л лога безопасности - на предмет информирования админа о попытках взлома.
6. аборт!
7. исполнение стандартного крон-кода.
Цитата(Alex B @ 13.08.2006, 11:47)
Спасибо за сведения.
Странное ценообразование (правдя это с Ваших слов, в реалии я такого не видел)!
Если на VDS делится между клиентами аж вся ОС, а тут лишь Апача, то это очень странно...
Ничего странного. Для автоматизации VDS существует готовое ПО, а для автоматизации раздачи апача - нет. Ручной или полуавтоматизированный труд всегда стоит больше автоматизированный.
Цитата
Вот те здрасте пожалуйста! С каких это пор чтобы отпарсить в утилите входную строчку на НЕ допустимые занчения параметров нужно перелопачивать всю ОС!???
Вы - прикладной программист, а не системный и объяснять взаимодействие крона с системой я не стану - нехватит времени.
Цитата
К тому же есть паллеатив. хотя более слабый в степени защиты: использвать парсилку прямо в Панели. Но тогда не будет защиты от вставки в кронтаблу чего-то непотребного иными хакерскими срадствами...
Еще раз. Повторяю. Медленно.
Я пишу у себя perl скрипт. В корн ставлю исполнение своего perl скрипта. Это нормально? Да.
А в самом скрипте я пишу нечто вроде cat /etc/passwd. Это нормально? Нет.
Но крон этого не проверит - он просто запустит perl на исполнение скрипта.
Теперь понятно?
Цитата
Аналогично вышенаписанному. Неужто трудно сообразить что если на хосте в скриптах разрешено испольнять ВСЁ, то на шареде о защите вообще следует забыть!
На Unix изначально разрешено исполнять все из /bin, /usr/bin.
Плохая ли команда cat? Нет. А ее использование в виде cat /etc/passwd - плохое.
Отключить команду cat пользователем? Не будет работать часть скриптов где она используется.
Цитата
Нужно же понимать что при любой нормальной настройке сервера из правильно сконфигрурированных языков не исполнить тот же вызов чтения/записи применительно к данным из чужой директории, а лишь разрешено это применительно к своей!
Что Вы говорите?
Это и так есть - по умолчанию. Другое дело что под mod_php все php скрипты работают под одним пользователем - это и есть потенциальная уязвимость.
Цитата
А причем здесь это? Если юзер вообще всё и для всех откроет у себя - это проблемы того юзера. В данной теме я чётко обозначил проблему и даже дал её решение "вручную". Зачем же так утрировать и передергивать то?
Не называйте тогда охально все проблемы пользователей "отмазками".
Цитата
Полагаю что это от того что там запрещено всё что абсолютно не есть необходимо на хосте. Последнее - из перечня услуг этого бесплатного шареда...
А Вам какой хостинг нужен - защищенный или функциональный?
Цитата(Alex B @ 13.08.2006, 13:19)
7. исполнение стандартного крон-кода.
Ага. И в php скрипте, который лежит в homedir находится запуск команды которая ищет на сервере все директории с правами типа 777
))
По поводу r5shell.
1. Нормально, форумы должны не разрешать заливать файлы с расширениями .php .phtml и подобные, а разрешенные для upload файлы (рисунки, txt) не должны выполнятся как скрипты по настройке сервера.
2. Элементарно поставить скрипт, хоть на ежедневный крон, который сканирует /home на предмет определенных слов (r57shell, void.ru, viewshell и т.д.) и что-то с этим делает, например пишет этот список на мыло или даже отсылает сразу клиенту (у нас так реализовано). А дальше уже дело клиента - удалить файл и понять почему он туда попал или нет.
1. Нормально, форумы должны не разрешать заливать файлы с расширениями .php .phtml и подобные, а разрешенные для upload файлы (рисунки, txt) не должны выполнятся как скрипты по настройке сервера.
2. Элементарно поставить скрипт, хоть на ежедневный крон, который сканирует /home на предмет определенных слов (r57shell, void.ru, viewshell и т.д.) и что-то с этим делает, например пишет этот список на мыло или даже отсылает сразу клиенту (у нас так реализовано). А дальше уже дело клиента - удалить файл и понять почему он туда попал или нет.
Цитата(MIRhosting.com @ 13.08.2006, 14:57)
По поводу r5shell.
1. Нормально, форумы должны не разрешать заливать файлы с расширениями .php .phtml и подобные, а разрешенные для upload файлы (рисунки, txt) не должны выполнятся как скрипты по настройке сервера.
2. Элементарно поставить скрипт, хоть на ежедневный крон, который сканирует /home на предмет определенных слов (r57shell, void.ru, viewshell и т.д.) и что-то с этим делает, например пишет этот список на мыло или даже отсылает сразу клиенту (у нас так реализовано). А дальше уже дело клиента - удалить файл и понять почему он туда попал или нет.
Что ж в полне с Вами согласен. Нужен такой мониторинг на всех шаредах! Жаль что это не далается "в принудительном порядке" уже в предустановленных скриптах...
В дополнение: туда же неплохо бы добавить сканирование всех юзерских директорий корневого класса (public_html и директорий корня _каждого_ субдомена) на предмет установки правильных прав - наверно разумное значение: 750 (хотя может быть в каких то иных конфигурациях сервера они могут быть иные). Это сделать несложно и это вполне эффективно против "нерузумных ручек" как юзеров, так и багов - как оказалось прояснённым в этом топке - просчета разработчиков спанели.
Попытаюсь набраться терпения и завергшить наконец этот тред дискусии...
Вы писали: "Для автоматизации VDS существует готовое ПО, а для автоматизации раздачи апача - нет" - неужели же тот метод, что Вы предлагали - раздача апачей - менее привлекателен чем раздача целых ОС, так что никто не удосужился реализовать и тут автоматизацию? Но может быть он технически не совершенен. Если же так, то и упоминать его едва ли стоит.
Пусть торжествует VDS - он в самом деле уже выходит на большую арену и стал недорог...
Вы писали: "Вы - прикладной программист, а не системный и объяснять взаимодействие крона с системой я не стану - нехватит времени" - но какое взаимодействие с системой? если речь идёт всего лишь о контроле за переданной строкой параметров?
Усложняете Вы вопрос лишь искусственно...
> Еще раз. Повторяю. Медленно.
> Я пишу у себя perl скрипт. В корн ставлю исполнение своего perl скрипта. Это нормально? Да.
> А в самом скрипте я пишу нечто вроде cat /etc/passwd. Это нормально? Нет.
> Но крон этого не проверит - он просто запустит perl на исполнение скрипта.
И я повторяю в который раз: можно ли считать на шареде номальным если из перл/пхп скриптов любой рядовой юзер без рутовых прав может делать ТАКОЕ?
Я считаю категорически НЕТ!
Но если на сервере ВСЁ ЭТО не позволется иными механизмами защиты, то ваш аргумент повисает в воздухе.
Моё же утверждение о необходимости и даже лёгкости под кроном проверить что юзера подсунут туда - напротив РУЛИТ!
ВЫ писали: "Плохая ли команда cat?" - Вы опять предаётесь пустой риторике!
Неужто Вы будете всерьёз утверждать что из скритов на шареде кому-то нормальному юзеру - а не злобному хакеру - ЭТА И ПОДОБНЫЕ ЕЙ КОМАНДЫ - реально нужны? Повторяю: на шареде без доступности юзеру какого-либо шелла!!!
Достаточно же ф-ций перл/пхп что позволят БЕЗОПАСНО делать всё - но лишь из того что _реально_ нужно и МОЖНО делать в скриптах рядовым юзерам.
Вы пишете "Отключить команду cat пользователем? Не будет работать часть скриптов где она используется" - именно так!
Те скрипыт которые её используют - на грани фола!
Пусть такие юзера берут VDS как вы мне упорно предлааете здесь. Мне такие команды внутри работы аккаунта не были нужны никогда... (Прошу не "путать" с работой в юниксе под шеллом как админ! и прошу не начинать тут очередную беспредметную волну выяснений очевидных вещей.)
Вы писали: "Другое дело что под mod_php все php скрипты работают под одним пользователем - это и есть потенциальная уязвимость." - с этим невозможно не согласиться. Но все таки лучше "потенциальная" чем реальная и совсем не прикрытая уязвимость. Если вообще не баг разработчиков...
Я писал: "А причем здесь это? Если юзер вообще всё и для всех откроет у себя - это проблемы того юзера. В данной теме я чётко обозначил проблему и даже дал её решение "вручную". Зачем же так утрировать и передергивать то?"
Вы в ответ писали: "Не называйте тогда охально все проблемы пользователей "отмазками"."
Я-то проблемы пользователей отмазками и не называл. Я называал отмазкою очень типичную и наблюдаемую посеместно манеру хостеров апеллировать к "возникновению уязвимости из-за ошибок юзера/скриптов юзера"...
Ну да оставим это. Тут никогда не найти общий язык между нами из де факто сложившайся сиутации когда хостер и юзер оказываются по разные стороны баррикады - не юзером воздвигнутой...
Вы писали: "А Вам какой хостинг нужен - защищенный или функциональный?" - мне нужно РАЗУМНО защищённый с разумными ограничениями - как "от дураков" так и от сознательного причинения вреда. Я не думаю, что это на самом деле противоположности или не реализуемо приемлемым способом.
Вы писали в конце: "...в php скрипте, который лежит в homedir находится запуск команды которая ищет на сервере все директории с правами типа 777" - см. моё разжевывание ситуации выше. Такое не может бвть разрешенным на шареде.
Более на эту тему толочь воду в ступе едва ли имеет смысл.
Если "сторона" хостинг-провайдеров встаёт СТЕНОЙ против разумных мер усиления безопасности - это заставляет юзеров задуматься и принимать меры собственной безопасности иными способами. В конце концов давно сказано: "спасение утопающих дело рук самих утопающих".
Вы писали: "Для автоматизации VDS существует готовое ПО, а для автоматизации раздачи апача - нет" - неужели же тот метод, что Вы предлагали - раздача апачей - менее привлекателен чем раздача целых ОС, так что никто не удосужился реализовать и тут автоматизацию? Но может быть он технически не совершенен. Если же так, то и упоминать его едва ли стоит.
Пусть торжествует VDS - он в самом деле уже выходит на большую арену и стал недорог...
Вы писали: "Вы - прикладной программист, а не системный и объяснять взаимодействие крона с системой я не стану - нехватит времени" - но какое взаимодействие с системой? если речь идёт всего лишь о контроле за переданной строкой параметров?
Усложняете Вы вопрос лишь искусственно...
> Еще раз. Повторяю. Медленно.
> Я пишу у себя perl скрипт. В корн ставлю исполнение своего perl скрипта. Это нормально? Да.
> А в самом скрипте я пишу нечто вроде cat /etc/passwd. Это нормально? Нет.
> Но крон этого не проверит - он просто запустит perl на исполнение скрипта.
И я повторяю в который раз: можно ли считать на шареде номальным если из перл/пхп скриптов любой рядовой юзер без рутовых прав может делать ТАКОЕ?
Я считаю категорически НЕТ!
Но если на сервере ВСЁ ЭТО не позволется иными механизмами защиты, то ваш аргумент повисает в воздухе.
Моё же утверждение о необходимости и даже лёгкости под кроном проверить что юзера подсунут туда - напротив РУЛИТ!
ВЫ писали: "Плохая ли команда cat?" - Вы опять предаётесь пустой риторике!
Неужто Вы будете всерьёз утверждать что из скритов на шареде кому-то нормальному юзеру - а не злобному хакеру - ЭТА И ПОДОБНЫЕ ЕЙ КОМАНДЫ - реально нужны? Повторяю: на шареде без доступности юзеру какого-либо шелла!!!
Достаточно же ф-ций перл/пхп что позволят БЕЗОПАСНО делать всё - но лишь из того что _реально_ нужно и МОЖНО делать в скриптах рядовым юзерам.
Вы пишете "Отключить команду cat пользователем? Не будет работать часть скриптов где она используется" - именно так!
Те скрипыт которые её используют - на грани фола!
Пусть такие юзера берут VDS как вы мне упорно предлааете здесь. Мне такие команды внутри работы аккаунта не были нужны никогда... (Прошу не "путать" с работой в юниксе под шеллом как админ! и прошу не начинать тут очередную беспредметную волну выяснений очевидных вещей.)
Вы писали: "Другое дело что под mod_php все php скрипты работают под одним пользователем - это и есть потенциальная уязвимость." - с этим невозможно не согласиться. Но все таки лучше "потенциальная" чем реальная и совсем не прикрытая уязвимость. Если вообще не баг разработчиков...
Я писал: "А причем здесь это? Если юзер вообще всё и для всех откроет у себя - это проблемы того юзера. В данной теме я чётко обозначил проблему и даже дал её решение "вручную". Зачем же так утрировать и передергивать то?"
Вы в ответ писали: "Не называйте тогда охально все проблемы пользователей "отмазками"."
Я-то проблемы пользователей отмазками и не называл. Я называал отмазкою очень типичную и наблюдаемую посеместно манеру хостеров апеллировать к "возникновению уязвимости из-за ошибок юзера/скриптов юзера"...
Ну да оставим это. Тут никогда не найти общий язык между нами из де факто сложившайся сиутации когда хостер и юзер оказываются по разные стороны баррикады - не юзером воздвигнутой...
Вы писали: "А Вам какой хостинг нужен - защищенный или функциональный?" - мне нужно РАЗУМНО защищённый с разумными ограничениями - как "от дураков" так и от сознательного причинения вреда. Я не думаю, что это на самом деле противоположности или не реализуемо приемлемым способом.
Вы писали в конце: "...в php скрипте, который лежит в homedir находится запуск команды которая ищет на сервере все директории с правами типа 777" - см. моё разжевывание ситуации выше. Такое не может бвть разрешенным на шареде.
Более на эту тему толочь воду в ступе едва ли имеет смысл.
Если "сторона" хостинг-провайдеров встаёт СТЕНОЙ против разумных мер усиления безопасности - это заставляет юзеров задуматься и принимать меры собственной безопасности иными способами. В конце концов давно сказано: "спасение утопающих дело рук самих утопающих".
Цитата(Alex B @ 13.08.2006, 17:07)
Более на эту тему толочь воду в ступе едва ли имеет смысл.
Сейчас я произнесу волшебные слова, после которых обе спорящие стороны объединятся. Против меня одного, естественно
.Любой хостер, использующий любую панель управления массового распространения (коммерческую, бесплатную - не суть важно), проигрывает в обеспечении безопасности клиентских сайтов тому хостеру, кто не использует панели вообще или пишет их сам. Аргументировать надо?
И попробуйте убедить меня в обратном. А вы тут спор развели вокруг одной
. Будьте справедливы, не забывайте и обо всех остальных.
Цитата(Alex B @ 13.08.2006, 15:07)
Это сделать несложно и это вполне эффективно против "нерузумных ручек" как юзеров, так и багов - как оказалось прояснённым в этом топке - просчета разработчиков спанели.
Если это актуально (для хостеров), то можно написать скрипт который будет править права на аккаунты - делов то на полчаса.
[quote name='Alex B' date='13.08.2006, 16:07' post='49166']
Попытаюсь набраться терпения и завергшить наконец этот тред дискусии...
Вы писали: "Для автоматизации VDS существует готовое ПО, а для автоматизации раздачи апача - нет" - неужели же тот метод, что Вы предлагали - раздача апачей - менее привлекателен чем раздача целых ОС, так что никто не удосужился реализовать и тут автоматизацию? Но может быть он технически не совершенен. Если же так, то и упоминать его едва ли стоит.
Пусть торжествует VDS - он в самом деле уже выходит на большую арену и стал недорог...
[/quote]
Да, раздача апачей менее привлекательна. Ибо для раздачи VDS есть готовые платные и бесплатные решения, а для раздачи апачей - нет. Неудосужился никто реализовать это - ибо незачем.
[quote]Вы писали: "Вы - прикладной программист, а не системный и объяснять взаимодействие крона с системой я не стану - нехватит времени" - но какое взаимодействие с системой? если речь идёт всего лишь о контроле за переданной строкой параметров?[/quote]
Контролировать передоаваемую строку параметров - глупо. Я уже писал почему.
[quote]> Еще раз. Повторяю. Медленно.
> Я пишу у себя perl скрипт. В корн ставлю исполнение своего perl скрипта. Это нормально? Да.
> А в самом скрипте я пишу нечто вроде cat /etc/passwd. Это нормально? Нет.
> Но крон этого не проверит - он просто запустит perl на исполнение скрипта.
И я повторяю в который раз: можно ли считать на шареде номальным если из перл/пхп скриптов любой рядовой юзер без рутовых прав может делать ТАКОЕ?[/quote]
Может. Ибо утилита find/locate предназначена не только для рута.
[quote]Я считаю категорически НЕТ!
Но если на сервере ВСЁ ЭТО не позволется иными механизмами защиты, то ваш аргумент повисает в воздухе.
Моё же утверждение о необходимости и даже лёгкости под кроном проверить что юзера подсунут туда - напротив РУЛИТ![/quote]
Юзеры могут ничего не засовывать туда. Они могут закачать эксплоит и запустить его через крон. Эксплоит - бинарник. Так что никто никуда не рулит.
[quote]ВЫ писали: "Плохая ли команда cat?" - Вы опять предаётесь пустой риторике!
Неужто Вы будете всерьёз утверждать что из скритов на шареде кому-то нормальному юзеру - а не злобному хакеру - ЭТА И ПОДОБНЫЕ ЕЙ КОМАНДЫ - реально нужны? Повторяю: на шареде без доступности юзеру какого-либо шелла!!![/quote]
Да, нужны. И не только она, а множество других. Ибо одним phbb интернет не сыт
[quote]Достаточно же ф-ций перл/пхп что позволят БЕЗОПАСНО делать всё - но лишь из того что _реально_ нужно и МОЖНО делать в скриптах рядовым юзерам.
Вы пишете "Отключить команду cat пользователем? Не будет работать часть скриптов где она используется" - именно так!
Те скрипыт которые её используют - на грани фола![/quote]
Давайте тогда убъем php сразу. Априори - все php скрипты на грани фола
[quote]Пусть такие юзера берут VDS как вы мне упорно предлааете здесь. Мне такие команды внутри работы аккаунта не были нужны никогда... (Прошу не "путать" с работой в юниксе под шеллом как админ! и прошу не начинать тут очередную беспредметную волну выяснений очевидных вещей.)[/quote]
Вам - не нужны. А другим - нужны. Большинству. Берите VDS, раз у Вас такие требования...
[quote]Вы писали: "Другое дело что под mod_php все php скрипты работают под одним пользователем - это и есть потенциальная уязвимость." - с этим невозможно не согласиться. Но все таки лучше "потенциальная" чем реальная и совсем не прикрытая уязвимость. Если вообще не баг разработчиков...[/quote]
Разницы между потенциальной и реальной (реализованной) уязвимостью нет. Это лишь вопрос времени.
Это не баг разработчиков - это фича
[quote]Я писал: "А причем здесь это? Если юзер вообще всё и для всех откроет у себя - это проблемы того юзера. В данной теме я чётко обозначил проблему и даже дал её решение "вручную". Зачем же так утрировать и передергивать то?"
Вы в ответ писали: "Не называйте тогда охально все проблемы пользователей "отмазками"."
Я-то проблемы пользователей отмазками и не называл. Я называал отмазкою очень типичную и наблюдаемую посеместно манеру хостеров апеллировать к "возникновению уязвимости из-за ошибок юзера/скриптов юзера"...
Ну да оставим это. Тут никогда не найти общий язык между нами из де факто сложившайся сиутации когда хостер и юзер оказываются по разные стороны баррикады - не юзером воздвигнутой...[/quote]
Если мы начнем с того, что язык php имеет массу глюков - явных и скрытых, то придем к заключению что при использовании php в случае взлома будет виноват клиент
[quote]Вы писали: "А Вам какой хостинг нужен - защищенный или функциональный?" - мне нужно РАЗУМНО защищённый с разумными ограничениями - как "от дураков" так и от сознательного причинения вреда. Я не думаю, что это на самом деле противоположности или не реализуемо приемлемым способом.[/quote]
Так небывает. Доказать? Доказываю.
Аксиома раз - никто небывает доволен. Приминение к виртуалхостингу - если отключить одну функцию или утилиту, это приведет к удовлетворению запроса одного клиента и недовольству десятка других, которым эта функция жизненно необходима.
Аксиома два - чем больше кода - тем больше ошибок. Применение к виртуалхостину - если разрещить утилиту или функцию, это приведет к тому, что со временем кто-то взломает сервер или сайт используя ошибку в данной утилите/функции.
Доказано.
[quote]Вы писали в конце: "...в php скрипте, который лежит в homedir находится запуск команды которая ищет на сервере все директории с правами типа 777" - см. моё разжевывание ситуации выше. Такое не может бвть разрешенным на шареде.[/quote]
Может. И будет работать на большинстве shared хостингах.
[quote]Более на эту тему толочь воду в ступе едва ли имеет смысл.
Если "сторона" хостинг-провайдеров встаёт СТЕНОЙ против разумных мер усиления безопасности - это заставляет юзеров задуматься и принимать меры собственной безопасности иными способами. В конце концов давно сказано: "спасение утопающих дело рук самих утопающих".[/quote]
Разумных мер не существует. Более близкая к разумным мерам на shared - это использование php как cgi (phpsuexec) с правами на скрипты 700.
Однако если на дуальном ксеоне будут спокойно жить 250 аккаунтов с активным использованием php - cms, phpnuke и т.п., то на php как cgi сервер будет померайт.
Попытаюсь набраться терпения и завергшить наконец этот тред дискусии...
Вы писали: "Для автоматизации VDS существует готовое ПО, а для автоматизации раздачи апача - нет" - неужели же тот метод, что Вы предлагали - раздача апачей - менее привлекателен чем раздача целых ОС, так что никто не удосужился реализовать и тут автоматизацию? Но может быть он технически не совершенен. Если же так, то и упоминать его едва ли стоит.
Пусть торжествует VDS - он в самом деле уже выходит на большую арену и стал недорог...
[/quote]
Да, раздача апачей менее привлекательна. Ибо для раздачи VDS есть готовые платные и бесплатные решения, а для раздачи апачей - нет. Неудосужился никто реализовать это - ибо незачем.
[quote]Вы писали: "Вы - прикладной программист, а не системный и объяснять взаимодействие крона с системой я не стану - нехватит времени" - но какое взаимодействие с системой? если речь идёт всего лишь о контроле за переданной строкой параметров?[/quote]
Контролировать передоаваемую строку параметров - глупо. Я уже писал почему.
[quote]> Еще раз. Повторяю. Медленно.
> Я пишу у себя perl скрипт. В корн ставлю исполнение своего perl скрипта. Это нормально? Да.
> А в самом скрипте я пишу нечто вроде cat /etc/passwd. Это нормально? Нет.
> Но крон этого не проверит - он просто запустит perl на исполнение скрипта.
И я повторяю в который раз: можно ли считать на шареде номальным если из перл/пхп скриптов любой рядовой юзер без рутовых прав может делать ТАКОЕ?[/quote]
Может. Ибо утилита find/locate предназначена не только для рута.
[quote]Я считаю категорически НЕТ!
Но если на сервере ВСЁ ЭТО не позволется иными механизмами защиты, то ваш аргумент повисает в воздухе.
Моё же утверждение о необходимости и даже лёгкости под кроном проверить что юзера подсунут туда - напротив РУЛИТ![/quote]
Юзеры могут ничего не засовывать туда. Они могут закачать эксплоит и запустить его через крон. Эксплоит - бинарник. Так что никто никуда не рулит.
[quote]ВЫ писали: "Плохая ли команда cat?" - Вы опять предаётесь пустой риторике!
Неужто Вы будете всерьёз утверждать что из скритов на шареде кому-то нормальному юзеру - а не злобному хакеру - ЭТА И ПОДОБНЫЕ ЕЙ КОМАНДЫ - реально нужны? Повторяю: на шареде без доступности юзеру какого-либо шелла!!![/quote]
Да, нужны. И не только она, а множество других. Ибо одним phbb интернет не сыт
[quote]Достаточно же ф-ций перл/пхп что позволят БЕЗОПАСНО делать всё - но лишь из того что _реально_ нужно и МОЖНО делать в скриптах рядовым юзерам.
Вы пишете "Отключить команду cat пользователем? Не будет работать часть скриптов где она используется" - именно так!
Те скрипыт которые её используют - на грани фола![/quote]
Давайте тогда убъем php сразу. Априори - все php скрипты на грани фола
[quote]Пусть такие юзера берут VDS как вы мне упорно предлааете здесь. Мне такие команды внутри работы аккаунта не были нужны никогда... (Прошу не "путать" с работой в юниксе под шеллом как админ! и прошу не начинать тут очередную беспредметную волну выяснений очевидных вещей.)[/quote]
Вам - не нужны. А другим - нужны. Большинству. Берите VDS, раз у Вас такие требования...
[quote]Вы писали: "Другое дело что под mod_php все php скрипты работают под одним пользователем - это и есть потенциальная уязвимость." - с этим невозможно не согласиться. Но все таки лучше "потенциальная" чем реальная и совсем не прикрытая уязвимость. Если вообще не баг разработчиков...[/quote]
Разницы между потенциальной и реальной (реализованной) уязвимостью нет. Это лишь вопрос времени.
Это не баг разработчиков - это фича
[quote]Я писал: "А причем здесь это? Если юзер вообще всё и для всех откроет у себя - это проблемы того юзера. В данной теме я чётко обозначил проблему и даже дал её решение "вручную". Зачем же так утрировать и передергивать то?"
Вы в ответ писали: "Не называйте тогда охально все проблемы пользователей "отмазками"."
Я-то проблемы пользователей отмазками и не называл. Я называал отмазкою очень типичную и наблюдаемую посеместно манеру хостеров апеллировать к "возникновению уязвимости из-за ошибок юзера/скриптов юзера"...
Ну да оставим это. Тут никогда не найти общий язык между нами из де факто сложившайся сиутации когда хостер и юзер оказываются по разные стороны баррикады - не юзером воздвигнутой...[/quote]
Если мы начнем с того, что язык php имеет массу глюков - явных и скрытых, то придем к заключению что при использовании php в случае взлома будет виноват клиент
[quote]Вы писали: "А Вам какой хостинг нужен - защищенный или функциональный?" - мне нужно РАЗУМНО защищённый с разумными ограничениями - как "от дураков" так и от сознательного причинения вреда. Я не думаю, что это на самом деле противоположности или не реализуемо приемлемым способом.[/quote]
Так небывает. Доказать?
Доказываю.Аксиома раз - никто небывает доволен. Приминение к виртуалхостингу - если отключить одну функцию или утилиту, это приведет к удовлетворению запроса одного клиента и недовольству десятка других, которым эта функция жизненно необходима.
Аксиома два - чем больше кода - тем больше ошибок. Применение к виртуалхостину - если разрещить утилиту или функцию, это приведет к тому, что со временем кто-то взломает сервер или сайт используя ошибку в данной утилите/функции.
Доказано.
[quote]Вы писали в конце: "...в php скрипте, который лежит в homedir находится запуск команды которая ищет на сервере все директории с правами типа 777" - см. моё разжевывание ситуации выше. Такое не может бвть разрешенным на шареде.[/quote]
Может. И будет работать на большинстве shared хостингах.
[quote]Более на эту тему толочь воду в ступе едва ли имеет смысл.
Если "сторона" хостинг-провайдеров встаёт СТЕНОЙ против разумных мер усиления безопасности - это заставляет юзеров задуматься и принимать меры собственной безопасности иными способами. В конце концов давно сказано: "спасение утопающих дело рук самих утопающих".
[/quote]Разумных мер не существует. Более близкая к разумным мерам на shared - это использование php как cgi (phpsuexec) с правами на скрипты 700.
Однако если на дуальном ксеоне будут спокойно жить 250 аккаунтов с активным использованием php - cms, phpnuke и т.п., то на php как cgi сервер будет померайт.
Это текстовая версия — только основной контент. Для просмотра полной версии этой страницы, пожалуйста, нажмите сюда.