Нередко можно услышать, как на том или ином сайте в Интернет похозяйничали хакеры, изменив контент нужным им образом. И тогда среди широкой интернет-публики, не исключая и владельцев сайтов, обычно наблюдается скорее эмоциональная реакция, нежели трезвый анализ с производством необходимых выводов и адекватных действий.
С подобным случаем взлома недавно столкнулся и я. Но в отличие от прочих, я тщательно расследовал инцидент и собрал необходимую информацию. Узнав о ней и проанализировав собственную ситуацию на веб-сервере, каждый владелец теперь может сделать обоснованный вывод, повысив свою безопасность пребывания в Интернет.
Наиболее популярным (хотя бы в пределах Рунета) инструментом администрирования shared-вебсервера является cPanel, текущий релиз которой есть 10.8.2-RELEASE-119. По крайней мере, на некоторых хостерах при создании пользовательского эккаунта к нему сразу (т.е. по умолчанию) присоединяется Frontpage расширение. Видимым в папках домашней директории сайта (т.е. обычно в public_html) признаком этого является наличие структуры каталогов, начинающихся на _vti_, а в каталоге _vti_pvt лежит файл service.pwd, где в хешированном виде находится пароль на эккаунт пользователя. Защитой (как показала практика, весьма эфемерной) от доступа по http к нему по мысли разработчиков служит запись в файле .htaccess такого содержания:
# -FrontPage-
IndexIgnore .htaccess */.??* *~ *# */HEADER* */README* */_vti*
<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName <site.url>
AuthUserFile /home/<user_account>/public_html/_vti_pvt/service.pwd
AuthGroupFile /home/<user_account>/public_html/_vti_pvt/service.grp
=========
где <user_account> - это эккаунт пользователя, или по иному - его логин.
Ясно: получив доступ к файлу service.pwd, где пусть и в хешированном виде* находится пароль на эккаунт, хакер получает все средства, чтобы делать с пользовательским сайтом абсолютно всё, что ему желательно!
* примечание: ведь всем должно быть ясно, что в современных условиях вовсе не нужны компьютеры cray или иные из арсенала ФБР, чтобы хакер комфортно, у себя на компьютере, весьма быстро нашел первый подходящий пароль, дающий такой же хэш; это означает, что хакер получает ПОЛНЫЙ доступ к эккаунту этого пользователя...
Именно так и происходят характерные взломы там, где используется эта фишка, так было у меня: файл .htaccess оказался после взлома обнулённым (и/или переименованным), а хакер похозяйничал, как хотел, ибо получил доступ такого же уровня, как владелец эккаунта!
Тут присутствует известный "психологический" момент: если хостер не запретил использовать Frontpage, и особенно если эккаунт дефолтно создаётся с таким расширением (как было в моём случае), 99% юзеров даже не задумаются об их уязвимости (не посмотрят в эти папки, не проанализируют уязвимость, как я показал выше). Следствие чего является МАССОВАЯ уязвимость самой большой группы вебсайтов, располагающихся на "дешевых" хостингах (точнее - везде, где можно подключить эту фишку ТАКИМ СПОСОБОМ, и особенно если это делают предустановленные скрипты автоматически, и это проблема хостера)...
Не верю я в то, будто бы подобная фишка с Frontpage является недосмотром (тех же поставщиков cPanel). Напротив, при формальной "безобидности" и юридическом прикрытии "законности" использования подобных расширений оно является ПО СУТИ замаскированной backdoor ко многим пользовательским интернет-эккаунтам (следовательно, с их сайтами можно делать что угодно).
Делайте выводы, господа! Мы живём в эпоху информационных войн...
С уважением, администратор интернет-сервиса "Репетиторство XXI века" www.rxxi.info,
Андрей Микитенко
Примечание. Эта статья постоянно находится здесь: http://www.rxxi.info/pdf/security/one_of_s...brittleness.pdf

ПОСЛЕСЛОВИЕ, ДОБАВЛЕННОЕ ПОСЛЕ ОКОНЧАНИЯ ПРЕНИЙ В ТЕМЕ
Результатом публикации этой темы и обсуждения её лично для меня явилось подтверждение тех моих давних наблюдений и наступившая уверенность в моих давних предположениях, что касаются положения дел в шаред-сегменте хостинг услуг.
Выводы в главном: всё возрастающие на глазах возможности, предоставляемые техникой и технологией (быстрый рост мощностей серверов с одновременным падением цен, а также совершенствование средств обеспечения выдачи и обработки веб-контента) ныне быстро начинают вступать в противоречие с моделями шаред-хостинга и политикой, однажды выбранной кем-то относительно способов виртуализации хостов. Следствием этого является предпосылки к ненадёжности обеспечения безопасности виртуальных хостов, следовательно падает безопасность сайтов клиентов, снижающаяся всё более и более в условиях крайне агрессивной современной "среды обитания", Интернета.
(Многие люди, причастные к этому сектору, до сих пор не пересмотрели расхожие мнения относительно условий и средств обеспечения безопасности, выработавшиеся в *никс среде ещё в давние времена и приемлемые лишь в условиях траст-сетей, т.е. скорее корпоративного интранета, нежели Интернета! Если же люди, причастные к хостингу, заявляют: де не следует требовать от хостинга в Интернет безопасности, - тем самым, они показывают свою профессиональную несостоятельность и отсутствие способности к здравым суждениям...)
Конечным следствием такого ненормального положения дел является уже случившаяся и быстро нарастающая маргинализация этого сегмента рынка.

Между тем оригинальные решения разработчиков по виртуализации хостов в рамках веб-сервера Апачи обеспечивали вполне приемлемые технические условия для разумной политики виртуализации хостов (необходимой для обеспечения возможности хостинга по разумно низкой цене) и одновременного обеспечения должной безопасности. Лишь пресловутый человеческий фактор является виной сложившемуся ныне ненормальному положению вещей в этом сегменте услуг. Техника и технология, наоборт, ныне как никогда обеспечила бы высочайший уровень услуг при низких ценах.
Нужно сказать, что сам по себе способ разделения ресурсов (шаред-хостинг) не является чем-то порочным или предрасполагающим к резкому понижению безопасности хостов. Но это верно лишь при условии, когда соблюдены известные технические приёмы и наложены разумные ограничения, вызванные скорее не технологией, а самим фактом наличия своеобразной "коммуналки" в пределах одного физического сервера. Если же разумности в этой политике не наблюдается*, тогда неудивительно наличие решений, препятствующих соблюдению обозначенной разумности в политике вирутализации хостов и управления ими. Что и ведёт к резкому снижению безопасности хостинга.
* Примечание: скажем, как наиболее типичное явление - жадность при "делении" физического сервера на как можно большее число виртуальных хостов, что непременно будет сопровождаться желанием выжать максимальную производительность, что в свою очередь приводит разработчиков автоматических "администраторов" - без них в реселлерстве не обойтись! - к желанию применить "решения", резко снижающие порог безопасности.
---
Вот это и есть причина наступающей здесь маргинализации. В таких условиях разумно требовательные клиенты несомненно будут уходить из этого сегмента в сегмент, где не наблюдается такого положения дел (ныне это VPS/VDS рынок услуг).
К счастью, этот и прочие новейшие технологические разработки по виртуализации более высокого уровня (выше уровня вебсервера) уже доступны по цене и ассортименту услуг, это будет нарастать впредь и развиваться (особенно при условии "перетекания" к ним массы клиентов с шареда).
Между тем, по сугубо техническим факторам шаред вполне подходит очень многим клиентам и удовлетворяет требования всех интернет-проектов, которые:
а) не требуют слишком больших ресурсозатрат от сервера (это тривиально);
б) применённые решения не требуют чего-то большего, чем использование всех богатейших возможностей, заложенных в сетевых языках программирования. Т.е. не требуют запуска каких-либо сервисов, кроме ограниченного спектра предопределённых, навроде крона, или ныне многим необходимого WMSigner'а, проверенного и едва ли могущего создать проблемы. Прочие должны быть запрещены директивно!
(След-но, это автоматически означает запрет на запуск и любых как-либо загруженных хакерами инструментов взлома.) Если пользовательские проекты не требуют запуска специально написанных для проекта каких-либо *никс-приложений, они не могут представлять угрозы при размещении на шареде, но лишь при соблюдении там должных приёмов безопасности.
Любой юзесркий эккаунт на шареде должен быть "заперт" в пределах своей homedir, юзер ни какими доступными техническими средствами не имеет право и не должен иметь возможность читать любые прочие данные и исследовать конфигурацию хостов "соседей". Из скриптов ДОЛЖНО БЫТЬ разрешено исполнять лишь те команды и запускать лишь такие приложения, что предопределены известными правилами, которые проверены годами (на предмет того, что такие ресурсы не могут представлять угроз).
Несоблюдание же всего этого вызвало бы явное снижение безопасности - не только для своего виртуального хоста, но и для вебсервера в целом, след-но, угрожало бы безопасности всех "соседей".

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

ПРАКТИЧЕСКИЙ ВЫВОД.
Не следует забывать, что любой "переезд", даже виртуальный, требует от владельцев ресурса усилий и затрат времени, а часто и немалых средств или риска потери клиентов из-за перебоев работы сайта. Поэтому ныне как никогда уже при начале работ над проектом требуется семь раз подумать, прежде чем отмерить и взять шаред-хостинг, даже если проект не нуждается в нестандартных технических решениях или даже "навырост" не потребовал бы высоких ресурсозатрат...

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

РуВеб совершенно прав!
Способ рискованный ну и опасный соответственно!

И заголовок темы исправили бы чтоли... "Взлом shared-вебсервера" и "взлом аккаунта c FrontPage на shared-вебсервере" это 2 большие разницы, не находите?
А "фишка" эта наверняка и не является недосмотром разработчиков панелей управления, а видимо является штатным режимом функционирования FrontPage. Который при адекватных настройках безопасности веб-сервера, и отсутствии дыр в скриптах пользователя опасности не представляет, как мне кажется.

Зачем что либо придумывать если можно и так пошаритсья по всем аккаунтам получив лиш данные из /etc/passwd и зная какая архитектруа папок на данном сервере в /home/

Если на хоме стоят права 711 а напапках юзеров 711 это не значит что по этим папкас нельзя шариться!

А если учесть что cpanel пашет везде стандартно, то на любом cpanel хостинге можно из 200-300 аккантов на сервере найти от 5 до 20 акканутов где можно найти папку, в которую можно записать что-либо, а дальше уже дело техники

Это зависит откуда взламывать - имея досутп на самом сервере или из вне.
Если снаружи - тогда проблема в слабых паролях (атака по словарю).
Если изнутри - тогда проблема в правах. Нужно использовать 750/640 права.

Не преувеличивайте. Не на любом, а только на криво настроенном.

Но согласен, что это проблема скорее не Cpanel, а админов малограмотных или малоопытных.

eSupport.org.ua,
Ну внутри если апач пашет от nobody xx0 права ставить проблемно!
А доступ внутрь получить можно легально купив хостинг!

И что же вы будете искать?

Права user:nobody 750 без проблем ставятся на public_html и юзером чужим вы внутрь этой папки уже не пролезете. А апачем через php не даст пролезть safe_mode или open_basedir. Неужто вы об этом не знали?

Мне хватит найти папку, на которой юзер поставит 777 или хватит найти файл config.php с паролями от базы и стереть её или застопорить нормальную работу вашего MySQL сервер!



Не ужели в не знаете что не все клиенты приемлют safe_mode
Не ужели вы не знаете что многие юзара сами самостоятельно ставят на public_html права выit чем 750 только потому что во многих скриптах к которым есть документация рекомендуют ставитьправа как можно выше без учета безопасности в целом?
Не ужели вы не знаете что админы всех хостинг компаний не следять за всеми аккаунтами юзеров кто какие права ставит!

В итоге из 100-300 акканутов на одном сервере находтися много клиентов умников, которые позволяют себя взломать другим клиентам этого же хостинга! И это проблема с одной стороны клиентов, с другой то что админы не следят за этим автоматически снимая с важных папок высоких прав!!!

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

И что? Это их проблемы. Это не повод подвергать опасности аккаунты других клиентов. Не устраивает safe_mode/open_basedir - идите на хостинг, где php работает от юзера. Нет? Тогда забудте слово "безопасность".
Кстати, на наших серверах мы используем модифицированный вариант safe_mode, и никаких проблем с доступом из своих сктриптов к своим файлам у клиентов обычно не возникает. Единственное серьезное неудобство - невозможность запуска внешних программ (кроме WMSigner ;)
Это их проблемы. Они могут хоть пароль от аккаунта у себя на главной странице написать. Мы говорим о безопасности системы и дефолтовых настроек аккаунта, а не о том на какие глупости способен клиент.
А зачем? Если кто-то сам вырыл себе яму и понаделал дырок в безопасности _своего_ аккаунта - он сам себе злобный Буратина.

Повторяю в 4й раз. Это проблема "умников, которые позволяют себя взломать" и только их.

На счет safe_mode - это лечение перхоти гильотиной.
А open_basedir обойти не так уж и сложно

Как вам сказать. Вообще-то, для лечения именно этой "перхоти" safe_mode и был создан. Вполне приемлимое решение, как показала практика. Не намного лучше/хуже того же open_basedir.
Естественно, речь идет не об open_basedir самом по себе, а о некотором комплексном решении на его основе.

Все упирается в скрипты с уязвимостями и/или слабыми паролями. Само по себе Frontpage расширение уязвимости не дает.

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

Доступ можно в ПМ послать!

Я не исключаю, что у вас все супер настроенно, но вы это не 100% других хостинг компаний юзающих cpanel.

Да и желательно чтобы на сервере было не меньше 100-200 акканутов (и также желательно чтобы они были не на голых html страницах)

Неужели трудно сообразить, что когда в домашней папке сайта находится пароль, пусть и хешированный, это огромная дыра в безопасности?!
Две огроменные разницы, когда взломщику нужно шарить где-то в /etc/passwd (куда еще нужно добраться!), или в домашней папке сайта...

Это не дыра, а лишь потенциальная уязвимость. Если в ваших CGI-скриптах нет дыр (или если вы вообще не пользуетесь CGI) она вам ровным счетом ничем не грозит.
(А до /etc/passwd добраться легко, вот только пароли там не хранятся.)

Как вы прочтете пароль из config.php, если ещё не взломали сервер? И что вам даст знание пароля на MySQL? В норме он отличается от пароля на эккаунт.
Что вам даст нахождение папки с правами 777, если это не папка, где лежат и исполняются скрипты? (Да и как вы найдёте такую папку, ЕЩЁ не зломав эккаунт юзера?)

Да, CGI я не использую давным-давно, ибо есть PHP. Но папку для CGI все вирт. хостинги создают автоматически... (и к том уже папку пустую... в принципе это может как-то способствовать хитроумным комбинациям хакеров... или я не прав?)
Однако как вы сможете, являясь просто посетителем сайта (но с намерением взлома , добраться по http до папок сервера выше юзерского эккаунат? Поделитесь пожалуйста опытом (можно приватом на странице контакт у меня на сайте
P.S. приверен /etc/passwd разумеетя лишь как пример, он давно не актуален для взлома :^)

А нет. Я гоню. На нем же права 644, т.ч. прочитать его можно и php-скриптом под mod_php...
Если без safe_mode и open_basedir - то точно также - через относительный путь. Никакой принципиальной разницы нет.
Но мы с Drug'ом уже немного отходим от темы. Нас больше беспокоят способы добычи чужих данных, в случае когда злоумышленник имеет аккаунт на сервере.

Для того чтоб прочесть пароль из config.php необходимо иметь права чтения этого файла. А прочесть можно через php, openbasedir не спасет.
Знание пароля mysql даст возможность украсть базу.
А нахождение директории с правами 777 даст возможность залить туда свой скрипт и вызвав его из вне - получить полный доступ к аккаунту.




safe_mode исключает нормальную работу многих скриптов. Тогда уже проще вообще php отключить

У кого-то - исключает, у кого-то - нет

ClayRabbit wrote:
"Если без safe_mode и open_basedir - то точно также - через относительный путь."
Вы хотите сказать, что в таком случае из одного юзерского эккаунта спокойно можно прочесть данные, лежащие в папках другого эккаунта, и ниакаеи права на папки не спасают от такой операции?

ClayRabbit wrote:
"Но мы с Drug'ом уже немного отходим от темы. Нас больше беспокоят способы добычи чужих данных, в случае когда злоумышленник имеет аккаунт на сервере."
И я о том же... Изначально я очень сормневался, что вся операция взлома, которую я вкратце описывал в топике, может быть осуществлена "извне" по хттп... Явно есть дыры в настройках хостинга (хотя хостер уверял, что таковых нет), позволяющие дерибазнуть "соседа"... ;)

eSupport.org.ua wrote:
"Для того чтоб прочесть пароль из config.php необходимо иметь права чтения этого файла. А прочесть можно через php, openbasedir не спасет."
Дык вопрос в правах и стоит... Или простой операцией fopen() я могу открыть этот файл из своего эккаунта, и защита не спасёт? Если так, то о какой безопасности шаред-севера можно вообще говорить?..

eSupport.org.ua wrote:
"Знание пароля mysql даст возможность украсть базу."
Цитата из хелпа IBM: "Меню Save As служит для сохранения файла под нужным именем". ;-)))
А если серьёзно, то в контексте топика и вообще здешнего разговора я не вижу РЕАЛЬНОЙ пользы от кражи mysql пароля... Или я что-то не знаю, и оная пользв хакеру всё же есть?

eSupport.org.ua wrote:
"А нахождение директории с правами 777 даст возможность залить туда свой скрипт и вызвав его из вне - получить полный доступ к аккаунту."
Залить как? Неужели по хттп, или всё же из своего эккаунта - "соседу"?
Мы похоже в общении как-то терям нить и путаем взлом чисто извне и изнутри "от соседа"...

phpSuexec рулит

shell только chroot`овый

разъяснение клиентам правила установки прав на сервере и что это значит для их безопасности

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

ну про своевременный апдейт системы и всего что на ней установлено я не говорю

И можно ли считать нормальным (для безопасности сервера), что из своего эккаунта юзер может прочесь через fopen() тот же /etc/passwd ?

to Andrew Mikitenko
Если Вас интересует конкретные сценарии взломов, легкий поиск в интернете даст много информации. В большинстве случаев взлом делается пионерами которым нефиг делать летом, они скачивают с определенного сайта уже готовый скрипт/сценарий взлома и сканируют сайта до посинения, а точнее до нахождения ресурса который может быть взломан. В большинстве случаев это уязвимые скрипты, особенно часто форумы.

http://securitylab.ru
http://opennet.ru

и множество других

бесполезная потеря времени

Простой операцией - нет. Чуть более сложной - да.

mysql пароль даст доступ к дампу mysql. Украсть базу или взломать.

Залить изнутри - соседу. Что на shared хостинге очень легко сделать - заказать хостинг

Если вы про "PHPSuexec is the shortened term often used to describe running PHP as a CGI with Suexec.", то вроде бы это настолько же старО, насколько неэффективно в плане использования ресурсов...
Хотите сказать, на ваших серверах один пользователь "чуть более сложной операцией" может читать php-файлы другого?

Эхе-хе, давно это уже было. Все довольно подробно перетирали тут - http://phpclub.ru/talk/showthread.php?threadid=47772 Кстати, с тех пор какие-то принципиально новые и реально работающие решения появились?

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

rustelekom, см выше. 750 на public_html и все.

На тех серверах которые мы сетапим, эти "чуть более сложные операции" отключаем
Просто не хочу писать как, чтоб не плодить кульхацкеров. Если интересует - в приват.



Для perl, под freebsd было решение совать скрипты в jail.
Просто когда видно чей процесс хулиганит - проще найти.

А можно ли ЗАКРЫТЬ Перл в спанелевскоих серваках для отдельного юзерского эккаунта, ежели оный юзверю вообще не нужен, чтобы повысить безопасность своего экаунта? Если да, то как?
(Кстати, что будет, если юзер удалит предопределённую директорию cgi-bin ?)

Вот поэтому наверное для некоторых эккаунтов хостер назначает /usr/local/cpanel/bin/jailshell
Или я неправ?

Хм. А почему вы думаете, что другие не отключают? По-моему, все эти схемы давным-давно известны и не раз обсуждались на множестве форумов.

Насколько мне известно, на CGI-скрипты это никакого эффекта не производит, т.ч. пользы от него не шибко много.

Господа!
Тема явным образом расплылась по типу "в огороде бузина, а в киеве дядька"... (это не упрёк, а констатация факта).
Чтобы немного упорядочить разговор, хотелось бы вкратце подбить предварительные бабки, приглашая высказаться именно по этой теме.
1. Можно ли считать нормальным и безопасным, если хостер дефолтно (между прочим, на базе сервиса сПанели) предоставляет (при открытии) эккаунту такие небезопасные фишки, как описанная в топике?
2. Можно ли считать нормальным и допустимым, когда любой юзверь может прочесть чувствительные данные (тот же /etc/passwd !) из своего эккаунта? - и это в условиях, когда шаред стал без натяжек грошовый, и даже многие хостеры предоставляют тестовый эккаунт, а регистриция фактически анонимная, взять хостинг лишь затем, чтобы "насолить соседям" - дело пустяковое...
(IMHO, едва ли это нормально даже на шареде. Если мне не изменяет память, годах этак в 96-98-х, когда хостинг стоил 8-15 баксов, но был при этом, безусловно, - за эту цену, - тоже шаредовый, используя fopen() я не мог бы прочесть тот же /etc/passwd - и это есть нормально!)
3. Не верю я, что нет "дешевых" (не ресурсозатратных) способов посадить веб-юзверей в jail dir'sы, чтобы они не баловали и не парсили, ни эккаунты друг друга, а тем более не имели бы возможности читать системные ф-лы...
4. Не верю я в то, что сПанель не имеет багов и скрытых недокументированных возможностей, как любая весьма сложная система! (Конечно, я не могу аргументированно доказать этого, самостоятельно исследовав её исходники, ибо не имею ни желания, ни времени брать это изделие и копаться в нём - я НЕ хакер и НЕ занимаюсь хостингом, поэтому мне это было бы излишней тратой сил и времени...) Следствием этого является дополнительная уязвимость шаредов, наверно на 95% юзающих именно её...
5. Можно ли считать нормальным, когда Перл (ныне уже довольно мало используемый, но с повышенной опасностью исп. для хака) дефолтно доступен ВСЕМ шаред-юзерам? (а не включается, как и фронтпага, лишь вручную из сПанели тем юзером, кому это реально нужно; тогда решившись на это, он САМ уж и несёт ответственность за сей рискованный шаг...)
6. Можно ли считать нормальным, если сПанель конфигурирует эккаунт так, что чувствительные папки находятся ВНУТРИ public_html ?! (Когда-то и это было не так, и подобные папки админами выносились/создавались (вручную?) в домашнем (серверном) пользовательском директории.)
Вот пока всё - как предварительный итог дискуссии.

1. Воздержусь от оценки.
2. /etc/passwd - это не чувствительные данные. Файлы с чувствительными данными как минимум либо не не должны иметь аттрибута world read, либо должны находиться в папках не имеющих аттрибута world execute.
3. Есть, но они сопряжены с некоторыми неудобствами для клиентов.
4. Я бы на вашем месте, особенно в контексте данного топика, больше беспокоился об отсутствии багов в скриптах, которые вы используете. Ибо в 99% случаев все взломы происходят через них, и никакой хостер вас от ваших собственных скриптов не защитит.
5. На нормально настроенном хостинге, перл в руках одного пользователя, никакой опасности для других пользователей не представляет. А в отсутствие скриптов доступность perl'a не несет никакого риска и для самого владельца аккаунта. Perl это всего лишь одна из многих. Есть еще php (не mod_php), python, bash и множество других программ, с помощью которых можно сделать то же, что обычно делается с помощью perl'а. (В конце-концов могут быт вообще бинарники откомпилированные пользователем.)
6. Да, можно, если при этом к ним нет открытого доступа по http. В таком случае, чаще всего нет никакой разницы лежат ли они в public_html или уровнем выше.

В дополнение.
7. Можно ли считать нормальным, что сПанель создаёт дефолтный анонимный ФТП вход (у юзера всегда появляется каталог public_ftp) ?! Между тем, любое грамотное руководство по администрированию и безопасности под Юникс пишет, что анонимный ФТП лучше выносить куда-то на отдельный хост, если вам он воообще нужен! Так начерта сПанель ДЕФОЛТНО делает юзверям ТАКИЕ эккаунты?! И хотя при попытке соединиться с этим входом говорится autentification requred, - IMHO, это все же как-то, хоть немного, понижает безопасность шаредовых эккаунтов на базе сПанели...

7. Да, можно. Никакой особой опасности в этом нет.

2. возможность чтения /etc/passwd - это возможность для хакера исследовать структуру сервака...
3. какие неудобства, поконкретнее пож-ста.
4. почему вы думаете, что у меня баги в пхп-скиптах? Я юзаю лишь документированные возможности, и насколько это в силах человечеких, слежу за вопросами безопасности... Ваше утвержение, если принять во внимание мою реальную ситуацию, означало бы признание багов в САМОМ ПХП, которые хакеры знают и используют для хака через оный (и законно используемый на сайте)...
5. создаётся впечатление, что тут вы отходите от модели шаред, и начинаете говорить "вообще"... но коммент.
6. дык дело-то в том, что в норме по http _должен быть_ доступ лишь к папке public_html - именно это есть норма безопасности!

Откуда такая твердая уверенность?

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

2. Какую структуру?... Вы о чем?... Если мы говорим, о конкретных панелях, то исследовать там нечего - структуры в 90% случаев типовые. Но и что с того?
3. Есть разные варианты, с разыми преимуществами и разными неудобствами. Именно по этому поводу тема и "расплылась".
4. Потому что, при условии, что в ваших пхп-скриптах нет дыр - описанная вами в первом посте ситуация никакой опасности для вас не представляет - файл этот нельзя будет прочесть через http. (Предотвратить возможность доступа к данному файлу от других пользователей сервера - задача хостера - если она не выполнена, то о безопасности речи быть не может вообще.)
5. Нисколько не отхожу. Как ни странно, на шареде до сих пор многие пользуются и perl, и python, и собственными бинарниками (parser, например).
6. Не понял я вашей фразы.
7. Вы можете сказать какую опасность это представляет? До тех пор пока не выяснено что это опасно - это будет считаться нормальным и приемлимым.
А то у вас получается: "я не знаю как именно это мне может повредить, но мне вот кажется что как-то может". Вообще-то на 100% безопасных систем не бывает в принципе. Так может не пользоваться хостингами с панелями управления вообще? Каждый лишний компонент в системе увеличивает количество потенциальных уязвимостей. Так может тогда найти хостинг где вручную создадут аккаунт, где только апач и фтп, не пользоваться скриптами вообще и радоваться, что "это все же как-то, хоть немного" повышает безопасность сайта?

7. Кстати, насколько мне известно, в CPanel анонимный фтп-аккаунт по-умолчанию выключен - его надо отдельно включать через панель. А до тех пор public_ftp не более чем просто пустая папка. Т.ч. вопрос изначально некорректен. Меньше фантазий, больше фактов.

Общие соображения, навеяные диалогом в теме.
Когда я здесь упорно, раз за разом, показываю потенциальные уязвимости, присущие - не шареду как таковому, а именно сложившеся практике (не без системного влияния "идеологии", навязываемой сПанелью), - я не голословен и не "интуитивен". Напротив, опираюсь я на известный специалистам уже не один десяток лет принцип.
Вкартце, это даже математически легко может быть показано (хотя в любом конкретном случае непросто раздобыть достоверные стат. данные, которые можно было бы подставить в те формулы).
Уровень угрозы безопасности легко подсчитывается по эмпирической формуле:
Tmin ~= 1/(SUM (1/Vn)); (позже исправлено мною!)
где Vn - вероятность возникновения угрозы от _каждой_ (!!!) потенциальной возможности проникнуть в хост через ту или иную ошибку/недокументированную возможность, etc.
Т.е. суммируются величины, обратные вероятностям угроз. Но и это не всё! Есть ещё один уровень абстракции:
Tmax ~= 1/( (1/V1)*(1/V2)*(1/V3)... ); (позже исправлено мною!)
Это ПРОИЗВЕДЕНИЕ величин, обратных вероятностям угроз, и оно действительно в случаях, если учитывается и может быть исрользована злоумышленником не только каждая ОТДЕЛЬНАЯ вероятность проникновения, а может быть им использовнаа ЦЕПОЧКА из потенциальных дырок в системе (что "квалифицированные" хакеры как раз и задействуют в своих делишках)...
Умеющему мыслить логически и здраво, становится ясно, что чем больше "возможностей" (включая "сервисные удобства", не говоря уже о кол-ве языков, предустановленных скриптов и сервисов) в системе доступны рядовому юзеру, тем катастрофичнее дело с безопасностью системы!
Делайте выводы, господа!
ПРИМЕЧАНИЕ прошу пардону, господа, вначале в спешке я забыл в ф-ле взять ОБРАТНУЮ величину всего вычисляемого значения...


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

Верно. Вот только эпитет "катастрофичнее" тут не уместен, по-моему. Даже прочитав это все, думаю, мало кто станет искать хостинг под лозунгом "меньше возможностей за бОльшие деньги", а не наоборот
Вы же сами сказали, что мы имеем "разгул хакерста, при том - не столько "высокумного", сколько тупого "хулиганского". Так вот в том-то и дело, что 99% взломов на шареде сейчас происходит не с использованием различных "потенциальных" уязвимостей серверного ПО и их "цепочек", а с использованием вполне конкретных и ПУБЛИЧНО ИЗВЕСТНЫХ дырок, и в большинстве случаев это дырки в пользовательских скриптах.

2. Немало? И что вам даст эта информация (которую тем или иным способом можно и всегда можно было получить почти на любом шаред-хостинге с CGI)?...
Извините, но про _воображаемые_ опасности тут с вами дискутировать у меня больше нет желания - мы лишь преливаем из пустого в порожнее. Мне пока и с реальными забот хватает.

ПРОДОЛЖЕНИЕ.
Придётся, несмотря на занятость, "разжёвывать"...
4. Невозможность ПРОЧЕСТЬ ф-л через хттп не означает невозможности НАЙТИ в инете все или большинство хостов, где оные ТИПИЧНЫЕ решения использованы (а решения фронтпаги всем, кому интересно, известны вполне). Как это сделать: очень просто, но из этических соображений я здесь это не напишу. Но эта возможность означает, что если бы мне было нужно, я смог бы в полчаса написать скрипт, который пошарил бы по инету, используя БД имеющихся урлов, и надыбал бы себе уйму хостов, где подключена фронтпага. А поскольку в ней в каталоге, доступном (пусть и запароленом!) лежит запись с хешем ПАРОЛЯ ЭККАУНТА, то это столь лакомый кусочек, что любой уважающий себя хацкер в лепешку расшибётся, чтобы найти какую-то иную дырку в сервере, чтобы ОБНУЛИТЬ или ПЕРЕИМЕНОВАТЬ ф-л /.htaccess (Лично у меня оказалось обе эти возможностим реализованными тем хакером - больше это сделать было некому, а служба хостера не смогла ответить конкретно, что или кто смогло бы сделать ЭТУ ОПЕРАЦИЮ помимо целей хакинга...)
Должно быть ясно любому профи (а здесь чайников вроде не наблюдается), что получить пароль на эккаунт - это на уровне вирт. хоста навроде получения рутовых прав в случае, если кто-то рвётся на весь сервер... Также любому профи должно быть ясно, что получить хэш пароля из shadow неизмернимо труднее (не взаломав весь сервак), чем получить то же самое из http-каталога с хешем пароля, как будто нарочно выставленного ПОЧТИ на всеобщее обозрение...
Относительно вашего пассажа, де "возможность доступа к данному файлу от других пользователей сервера - задача хостера - если она не выполнена, то о безопасности речи быть не может вообще" скажу: это из круга суждений - "всё или ничего". Или по-другому, мышление на уровне атомизма.
На самом деле любая безопасность складывается (а иногда умножается, см. моё объяснение постингом выше) из компонентов-угроз. А реализуется ли угроза от данного компоннта, это реально зависит от столь большого кол-ва факторов, что не поддаётся учёту. Поэтому умы тривиальные ныне склонны просто ОТБРАСЫВАТЬ угрозы, а не мыслить конструктивно и устаранять их согласно давным-давно известным принципам:
а) "если неприятность МОЖЕТ случиться, она - рано или поздно - случиться ОБЯЗАТЕЛЬНО" - закон Мэрфи;
б) "знание общих законов (закономерностей) освобождает человека от непосильной задачи и ноши видеть и находить мириады частностей повседневно" - мудрое изречение кого-то (не помню какого философа), лично мною усвоенное с младых ногтей.

5. Не вопрос в том, что и на шареде кто-то протащит нечто не вполне безопасное! (и вы же сами в самых первых постах этой темы говорили об этом, и я вовсе не возражал там вам: если кто-то подставится, натащив в эккаунт чего-то небезопасного то... "сам дурак"...)
Дело в ином. Решения сПанели (и это я знаю не один год!) ПРОВОЦИРУЮТ (понятно из-за чего) на слишком вольное и часто дефолтное использование массы "возможностей", не всегда и не всем реально нужных, но УЖЕ подключённых к заказнному хосту. Далее всякому, реально и здарво мыслящему, станет ясно, что это существенно понижает безопасность как вирт. хоста, так и сервака в целом.

6. Напиши и поясню по-другому. Тут я писал о том, что исходя из требований безопасности лишь к ф-лам чистого html + php-скриптам, что и лежат в public_html, должен быть http-доступ! Если же в оный каталог впихнуты (не юзверем, а сПанелью!) иные папки и там есть ф-лы, НИКАК НЕ ПРЕДНАЗНАЧЕННЫЕ к даже потенциальной возможности чтения по хттп, то это ничто иное, как весьма весомая угроза безопасности!!!
Старые умудрённые опытом и знаниями специалисты незря рекомендовали и сами всегда делали всякие иные папки ВЫШЕ www (public_html) папки - сразу в юзерской домашней директории сервака...

7. У меня отнюдь не получается так, как вы сказали. Если бы вы понимали, о чём говорится раз за разом в этой теме мною, вы бы не написали так. А знали бы тогда, что ни один ум не может заранее предусмотреть _всякую_ возможность, которую однажды реализует изощрённый ум хацкера. Зато вполне возможно так выстроить систему безопасности, когда минимизируются ВОЗМОЖНЫЕ риски. До нуля их не свести никогда, но минимизировать можно и ДОЛЖНО!
Что касается того, что папка public_ftp пуста: так ведь и папка public_html сразу после открытия эккаунта тоже пуста...
Если хотите, конкратно относительно ПУБЛИЧНОГО ФТП я могу описать вполне реалистичный краткий сценарий, думаю, всем "заинтересованным" известный и поэтому не погрешу против этики... (Забыл в п.7 добавить сразу, что в папке public_ftp есть и папка incoming - это означает, что туда можно ЗАЛИВАТЬ всё, что вошедший анонимно - если бы это позволялось, - или взломав ЭТОТ фтп-вход, если изначально этот вход запаролен... Это не фантазия, ибо я сам лично нашел у себя в эккаунте после взлома ф-л .htpasswd, которого у меня небыло ранее, и где содержится в точности тот хакерский пароль, который он сделал на эккаунт вместо моего...) Так вот, зная структуру эккаунтов и "возможности", предоставляемые текущими верисями сПанели, хакер - любым способом - от поиска беспечно открытых анонимных входов - до каких-то известных им приёмов взлома фтп - "заливает" в чей-то инкоминг фтв эккаунт свой хакерский "кит", а дальше... Нужно ли далее подробно расписывать серьёзность угрозы!
К тому же независимо от того, дефолтно открыт ли именно ПУБЛИЧНЫЙ (беспарольный) вход на фтп-эккаунт на шареде, это всё равно очень сильно понижает безопасность даже всего сервера, а не только вирт. хоста данного юзера. Это же азы юникс-безопасности!

Повторяю в сотый раз (не расходясь здесь и с вашей первоначальной оценкой): если какой-то юзер сам подключает через ту же сПанель ДОПУСТИМЫЕ (но не 100% безопасные) сервисы, и вообще добавляет что-то помимо абсолютно необходимых (ныне это http, ssi, php, mysql), то ОН ЛИЧНО И ОТВЕЧАТ по сути за всё это...

Далее небольшое "лирическое отсутпление"...
Будь я автором сПанели, я бы при попытке подключения юзером множества сервисов, скриптов и прочего, что выходит за рамки ~100% безопасного, предупреждал бы юзера навроде того:
"Подумали ли вы о том, что каждый дополнительный скрипт и сервисная возможность снижает безопасность вашего эккаунта? Релаьно ли необходимо она вам?.."
И уж конечно дефолтно я бы не ставил той же фронтаги и сходного с этим.
Впрочем, тут возможно самодеятельность конкретного хостера.
Во-первых, только однажды - у одного хостера из нескольких, с которым мне доводилось иметь дело, - я столкнулая с дефолтно подключённой фронтагой (замечу - мне она на фиг никогда не была нужна!)
Во-вторых, как только я сообщил саппорту о взломе и о том, что мною изложено и в топике, МГНОВННО эта фишка было ими отключено - ЧТО СОВЕРШЕННО ВЕРНОЕ РЕШЕНИЕ!
И я вовсе не в претензии к хостеру - ясно же, что многое в их деятельности "ведётся" решениями той же сПанели и её разработчиков, что уже растиражировано ими на пол-интернета...

Ну, если ВАМ милее лозунг: "получите за бакс хостинг, где усановлено и уже подключено с десяток фишек, ваш сайт будет _почти_ готов, (сварганенный из "кривых" шаблонов - последнее в лозунге НЕ ПИШЕТСЯ ;-))) ), да в придачу подключено дюжина полу-хакерских скриптов разного назначения", то... :^-))))
Относительно "качеств" хакерства вы же, будучи по все видимости спецом по хостингу, не можете не знать, что "пионеры", способные пользоваться лишь _готовыми_ "решениями" с хакерских и полу-хакерских сайтов, чтобы скоммунизьмить пароли или насолить людям, не сами всё это "изобретают"! Вы же знаете, что делают это вполне знаваемые личности с известными искривлениями морали, при том - чрезвычайно изощрёнными умами! И что "решения" эти по большей части нетривиальны и используют кучу возможностей КОМПЛЕКСНО, а отюдь не какую-то одну "дырку" (которые чаще всего быстро закрывают)...
Вам ли этого не знать:..
P.S. Всё, ухожу совсем на сегодня. Мне тоже надоело тратить время ПОЧТИ зря, разжёвывая для меня ОЧЕВИДНЫЕ вещи...

ДОПОЛНЕНИЕ. К тому же в своём стремлении "защитить честь мундира" (да ещё и по здравому смыслу - не своего...) Вы явно не в ладах даже с простой логикой...
Если бы хацкеры использовали "дырки" в ПОЛЬЗОВАТЕЛЬСКИХ скриптах, то В КАЖДОМ ОТДЕЛЬНОМ СЛУЧАЕ хакеру нужно было бы сначала исследовать этот пользовтаельский скрипт - каждый из нас, грешных, ошибается по-своему, а отнюдь не "стандартно"!
К тому же в норме никак невозможно, не взломав сначала сервер, скачать и изучить ТЕКСТ скрипта (неважно на перле или пхп), ибо при хттп-ВЫЗОВЕ скрипт ИСПОЛНЯЕТСЯ, и по хттп выдаётся РЕЗУЛЬТАТ, а никак не сам текст скрита! (И обойти это не представляется возможным в принципе - такова "физика" процессов.)
А вот известные СТАНДАРТНЫЕ ("сервисные") скрипты легко могут быть исследованы хацкерам - до посинеия и дырок в исходниках :-^))))

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