Недостаточная защищённость данных на 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 это сугубо неправильно и совершенно нелогично по жизни. Виртуальные то хосты в любом случае создаются, чтобы не сделать нормальный вебрут и докрут. Но,