ДОПОЛНЕНИЕ 2.
(Нарушаю собственное обещание, ибо "не могу молчать" - "пепел Клааса стучит в моём сердце" %=)) И хотя я очень-то не верю, что мои постинги способны как-то положительно повлиять на ситуацию в инет... всё же выскажу всё, что с годами наболело по этой теме. К тому же замечу, что я хотел сделать это ещё прошлый год, однажды поговорив на эту тему и с владельцем этого места, но всегдашняя текучка отвлекла, и лишь случившееся ЧП вернуло меня к этим "баранам".)

Сама старинная ситуация с "общедоступностью" тех данных, что отцы-основатели Юникса положили в /etc/passwd , а особено половинчатое решение при переносе лишь ЧАСТИ (фактически лишь хэш-пароля) важнейших системных данных в "тень", говорит о многом.
Но типичные "упёртые" и одновременно чрезвычайно амбициозные представители этого клана склонный "шаманить" и уповать скорее на "незнание чайников", на напускание словесного тумана, а не создавать для системы юникс/линух ТАКИЕ РЕШЕНИЯ, которые В ПРИНЦИПЕ практически не поддаются взломам.
Это не случаное свойство, а вполне системное, ибо все они не способны отходить от ДОКТРИН(ы). И поэтому всякие кардинальные изменения воспринимаются скорее "в штыки"... со всеми вытекающими из этого обстоятельствами.
Это не мой голословный навет, а моя рельность в видении ситуации, основанная на опыте (в том числе общения, видения их "слов и дел", etc.)
Ниже я хоть отчасти покажу это вкратце.
Ещё можно было как-то понять тех "отцов", кто в туманной и идиллической поре юности становления юникса впихнули в общедоступный ф-л пусть и запароленные, но критичнейшие данные. Тогда это отчасти были оправданы из-за в ту пору реальной нужды "экономии" в программных решаниях. Но никак не оправдано то, что при однажды принятом решении переноса в "тень" хэш-пароля и кое-каких других важных сведений, не было принято решение в ф-ле /etc/passwd оставить лишь ЛОГИН, да "х" как признак использования "тени" - и ВСЁ! А вот пароль, вместе с путями к домашней папке юзера и прочие _критичности_ тогда АБСОЛЮТНО ОБОСНОВАННО и без каких-либо проблем ОБЯЗАТЕЛЬНО НУЖНО было перенести в тень! (Ибо лишь админу с рутовыми правами ДОЛЖНО позволять видеть всё и находить в ф-ловой системе перс. юзерские папки.)
То, что это не было сделано, есть типично половинчатое решение, даже - решание неумное, и потому сильно облегчающее житие хацкеров...
Напротив, сочетание "тайности" пути к юзерской папке на сервере общественного доступа с очень простой практикой - при открытии эккаунта юзеру генерить название юзерского каталога как некий 8-10-символьный случайный маркер (что делается тривиально) означала бы чрезвычайно трудную для хакера работёнку, если он пожелал раскрыть это и попасть к юзеру в директорию (если ещё не получил рутовые права)...
Отчасти "полу-случайное" назначение вида строчки юзерского каталога практикуется ЧАСТЬЮ хостинг-провайдеров, а иные часто просто берут конкатенцию из частей урла домена 2-го уровня, делая это при регистрации нового клиента.
В ситуации же, когда любой "чайник" с лёгкосттью может прочесть ф-л passwd, все подобные потуги чуть-чуть "спрятать" юзера нисколько не затрудняют сбор данных об эккаунтах на данном конкретном сервере.


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

Можно. Там опция есть такая, в WHM. Более того можно сконфигурировать что по умолчанию не будет cgi.
Если удалить cgi-bin - не будет места для выполнения сриптов - работать небудут
Но на счет perl не переживайте - через php чаще ломают



Неправы. Это jailshell - для доступа через ssh.



По статистике большинство владельцев выделенных серверов понятия об этом не имеют.

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

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

если Вы про frontpage, то мы с Вами вместе убедились что наличие этого модуля самого по себе ничего не дает.



чтение /etc/passwd для всех пользователей - это необходимость работы системы. Вот чтение /etc/shadow - это уже дыра.


Есть. называется VPS. Обращайтесь
Делать каждому клиенту свой chroot апач с php - это извините дешевле VPS поставить.



А другие имеют время и возможность и иследуют ПО на уязвимости. И не была бы та же cPanel столь популярной до сих пор, если бы в ней были какие-то недокументарованные backdoor`ы. А баги везде есть, разница только в их степени опасности.



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


Не очень понял, про какие "чувствительные" папки идет речь Если Вы про cgi-bin, то я уже написал выше про это.

P.S. to Andrew Mikitenko
1) Подавляющее большинство взломов из-за уязвимостей в скриптах пользователей, а не в уязвимостей системы.
2) В Ваших руках на шаред хостинге сделать максимум для безопасности именно Вашего аккаунта.
3) Если Вам нужно абсолютная безопасность от соседей и гарантированность от взлома - выделенный сервер + ежемесячная подписка на услуги админа 1 категории + регулярные консультации с программистами высокого класса может быть тем минимумом, с которого можно начать.

1. И да и нет. Однозачно на такой вопрос не ответить.
2. Нормально абсолютно. Что такого даст /etc/passwd? Логины и домашние директории. И что дальше? Из под своего аккаунта не зайти - права. А из под апачевского (nobody) - зависит от настроек. Можно так закрутить что не зайти тоже.
3. Есть. Называется VDS - это более менее оптимально.
4. Ядро Linux с открытым исходным кодом. Если находят уязвимость - исправляют. cPanel хоть и платное ПО но поддержка его аналогичная - нахоят глюк - исправляют. А теперь вопрос - где лучше с security - в cPanel, за которой следят профи или в самодельном хостинге построеным человеком прочитавшим unix для чайников?
5. Укажите чем Perl более опасен чем php с точки зрения хака. Фронтпейдж можно просто стереть.
6. Укажите список чувствительных директорий внутри public_html




2. Каким образом /etc/passwd помогает исследовать структуру сервера? Системные пользователи - это не структура.
4. А при чем тут документированные возможности к глюкам? Например Вы можете не проверять передаваемые параметры и это будет уязвимостью. Хотя на вид все документировано. В php глюки тоже есть. Хотя его пишут на документированном C... странно, да?
6. А у Вас по http еще доступ к чему есть?

Вывод сделан. Через /etc/passwd выявить все сервисы нельзя. Что свидетельствует о недостаточном навыке работы с unix like OS...

Какие именно решения cpanel понижают security?

Какие именно файлы, которые не должны быть в public_html там расположены?

Вот Вам анонимный ftp - ftp.dedic.ru с директорией incoming - вход не запаролен. Сделайте что-то, чтоб не быть голословным...




Нет, это не так. Все ошибки достаточно стандартны и взломщики этим пользуются - переполнение буфера, sql-иньекции и т.п.




Все случаи взлома серверов (не хостинговых аккаунтов) начинались с того, что через уязвимость в php делался upload и exec эксплоита. И это говорит о том, что не нужно выламывать стену если калитка плохо прикрыта.
А уверенность программистов в надежности своих скриптов - это находка для взломщика.

eSupport.org.ua wrote: "Можно. Там опция есть такая, в WHM. Более того можно сконфигурировать что по умолчанию не будет cgi"
-- Спасибо!

eSupport.org.ua wrote: "Но на счет perl не переживайте - через php чаще ломают "
-- Это потому только, что а) пхп уже не один год статистически лидер популярности; б) при такиех решениях, как тиражирует другой сомнительный лидер, о котором тут говорится (спанель), это не удивительно... %)

rustelekom wrote: "не совсем понятны мотивы темы"
-- если это не очевидно из топика и тела темы, скажу в заключание кратко и тезисно:
1. привлечь внимание интернет-общественности к проблеме, которая есть, но о которой "заинтересованные лица" из данного сегмента интернет-услуг предпочитают умалчивать, недальновидно делая вид, "что всё в порядке".
2. показать рискованные решения (хотя бы частично, а не исчерпывающе, последнее требует слишком большого труда, особенно в условиях, когда "общественность" данного сегмента всеми силами сопротивляется здравому...) - которые, тем не менее, растиражированы на полмира такими "автоматизаторами".

rustelekom wrote: "в спанели на данный момент нет присущей именно есть уязвимости, когда такие находятся, об этом свовременно информирует и не ленивые админы могут их устранить"
-- именно есть, впрочем, как и почти любому "автоматическому админу"...

rustelekom wrote: "аналогично и с другими панелями"
-- не совсем: как и любая фишка, становящаяся "культовой", тяготеет к снижению "планки"... увы!

rustelekom wrote: "они просто идут за спросом, а спрос есть"
-- что из того, что есть спрос? - оный можно удовлетворять разными способами: одни будут объективно работать во благо, в том числе - на благо самого этого сегмента рынка услуг, другие - во зло, и этот факт когда-нибудь поспособствует упадку оного (чему сособствуют и объективные временнЫе факторы: уже грядёт и быстро дешевеет вирутализация вебсерверов иного, более высокого уровня абстракции...)

rustelekom wrote: "ну да, можно сделать почти неломаемую систему, но, для этого необходимо разрабатывать свою собственную панель. и многие крупные хостеры так и поступают"
-- и это заявление в том числе говорит о том, что проблема ТЕХНИЧЕСКИ решаема (что само по себе - не новость).
Что качается крупности - дык ведь и производитель сПанели - не мелкая лавочка...
Замечу известный факт: сама Апача, и ПХП, и Мускул (вместе или порознь используемые) имеют все заложенные в них технические предпосылки к тому, чтобы быть вполне устойчивой системой обеспечения веб-хостинга. Сама их популярность (вполне законная и заслуженная, также и по причине явно проступающих здесь преимуществ ГПЛ и Открытых Сорцов), что теперь уже явно и фактически всем видна; это говорит об их истинном, а "непопсовом", не "культовом" качестве. А вот когда надстройки админят сервачок так, как здесь мы все знаем, то... в том числе падает фактически вполне заслуженный престиж той же апачки как вполне устойчивого вебсервера...

rustelekom wrote: "кончили глобальными проблемами"
-- тем, кто презирает решение "глабальных проблем", всю оставшуюся жизни придётся ловить массово расплодившихся жуков... и крыс ;-))))

Ну что ж. Я не вижу резонов дальше продолжать здесь дискуссию. Мнения всех вполне прояснены.
В конце-концов, лично я не являюсь заинтересованным лицом - не принадлежу к вашему клану предоставления хостинг-услуг... (Хотя как любой, кто активно использует интернет и хостинг в профи-целях, разумеется, заинтересован в том, чтобы и оный сегмент был в исправности и работал на ОК!)

eSupport.org.ua wrote: "Какие именно решения cpanel понижают security?"
-- Вы хотите, чтобы я наххаляву произвёл сложнейший анализ? ;-))) да ещё и купил, и поставил себе на сервак сиё изделие (разумеется, чтобы получить доступ к кодам) - спасибо, вы чрезывычайно "умны" (за счёт других) и ... любезны...

eSupport.org.ua wrote: "Какие именно файлы, которые не должны быть в public_html там расположены?"
-- я уже писал парой-тройкой постингов выше об этом.
Впрочем, скажу и иное. Ещё прошлой осенью у меня были предложения к владельцу этого ресурса обсудить реальные непорядки, имеющиеся на шареде из-за той политики автоматического администрирования вебсервера, что внедрена в коды и потому растиражирована на полинета. Он сказал, что "заинтерсованные лица" хостинг-услуг будут сопротивляться честному и беспристрастному анализу этих вопросов. Так и вышло - даже по вполне ограниченному, частному вопросу из данного топика.
Конечно, я бы мог произвести тщательный анализ струкруры папок, что создаются спанелью (прочность её "политики" мне знакома, а нелепость решений по структуризации папок эккаунта знаема много-много лет) с публикованием результата в статье. Но пообщавшись со здешней публикой, мне уже расхотелось делать это: ибо тратить врамя зря мне не с руки.

eSupport.org.ua wrote: "Вот Вам анонимный ftp - ftp.dedic.ru с директорией incoming - вход не запаролен. Сделайте что-то, чтоб не быть голословным"
-- если вы меня за хацкера принимаете, то... спасибо! %;-))))

Кстати, а почему - дедик.ру, а не бэнкофамерика.сом ;-))))

eSupport.org.ua wrote: "Все случаи взлома серверов (не хостинговых аккаунтов) начинались с того, что через уязвимость в php делался upload и exec эксплоита. И это говорит о том, что не нужно выламывать стену если калитка плохо прикрыта. А уверенность программистов в надежности своих скриптов - это находка для взломщика."
-- "Волга впадает в Каспийское море"...
Впрочем, всё это не ново. Массовое сознание хостеров данного сегманта рынка не способно анализировать те вещи, которые когда-то видны были и вошли в золотой фонд программирования...

На __это__ не могу не ответить...

eSupport.org.ua wrote: "4. Ядро Linux с открытым исходным кодом. Если находят уязвимость - исправляют"
-- А кто здесь говорил об ядре линуха?

eSupport.org.ua wrote: "5. Укажите чем Perl более опасен чем php с точки зрения хака. Фронтпейдж можно просто стереть"
-- первое общеизвестно. Второе - спасибо за предложение (юзерам)! :_))) предложите это сделать ВСЕМ, кто юзает уже который год сиё издельице в инете...

eSupport.org.ua wrote: "Системные пользователи - это не структура"
-- ну, Вы это хацкерам объясните ;-)))) очень полезное замечание будет...

eSupport.org.ua wrote: "4. А при чем тут документированные возможности к глюкам? Например Вы можете не проверять передаваемые параметры и это будет уязвимостью. Хотя на вид все документировано."
-- кто _Вам_ сказал, что лично я не проверяю вообще всего, что критично, а не только "передаваемые параметры"?.. Ох уж это среднестатистическое массовое сознание...

eSupport.org.ua wrote: "6. А у Вас по http еще доступ к чему есть?"
-- ко всему, что предоставляет изделие под названием спанель.

eSupport.org.ua wrote: eSupport.org.ua wrote: "Вывод сделан. Через /etc/passwd выявить все сервисы нельзя. Что свидетельствует о недостаточном навыке работы с unix like OS"

Если Вы считаете, что фактически публичный доступ на вебсерваке к таким сведениям (см. список ниже) есть норма - то, что ж... ваше право!

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
apache:x:48:48:Apache:/var/www:/sbin/nologin
rpm:x:37:37::/var/lib/rpm:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/sbin/nologin
pcap:x:77:77::/var/arpwatch:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin
smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin
named:x:25:25:Named:/var/named:/sbin/nologin
rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
mysql:x:100:101:MySQL server:/var/lib/mysql:/bin/bash
xfs:x:43:43:X Font Server:/etc/X11/fs:/sbin/nologin
cpanel:x:32001:32001::/usr/local/cpanel:/bin/bash

Если вы НЕ ЗНАЕТЕ по каким именно причинам такая структура была выработана - это не повод называть эти решения нелепыми. Вы уже показали, что не разбираетесь в предмете. Это замечательно, что вы имеете общие теоретические познания о том, что файлы ОБЫЧНО безопасней размещать за пределами public_html. Но реальность такова, что (в случае наиболее часто использующейся сейчас с CPanel модели обеспечения php-безопасности) файл .htpasswd с правами 644, помещенный в папку /home/user/public_html/dir/ находится в безопасности, а если вы поместите его в созданный вами /home/user/dir/ - его сможет прочитать любой пользователь сервера.

И если ваш аккаунт был взломан, то праведный гнев свой следует обращать в первую очередь на вашего хостера (если только он вам не докажет что взлом произошел по вашей собственной вине), который не смог обеспечить должного уровня безопасности на сервере. CPanel никогда не была и никогда не будет идеальной. Она - не "культовая", она - ширпотреб. Для безопасной работы которого требуется прикладывать еще руки и мозги. При использовании такого ПО всегда приходится идти на какие-то ухищрения и компромисы, чтобы обеспечить приемлимый уровень безопасности. Далеко не идеальный, потому что все эти системы изначально проектировались не лучшим образом. (С другой стороны, система изначально нацеленная на максимальную безопасность наверняка стоила бы совсем других денег.) Но залатать наиболее крупные дыры своими силами хостеру гораздо легче, чем убедить разработчиков перепроектировать их продукт. И их можно понять. Просто _подавляющее большинство_ западных пользователей, а следовательно и большинство хостеров-покупателей этой панели эти дырки не волнуют.

Еще раз касательно первого поста. Да, это не очень хорошо. Да, фронтпедж не должен устанавливаться, если он не нужен клиенту. (Не уверен, что он способен функционировать в болеее безопасном режиме. Но кстати, системный пароль хешируется скорее всего по другому алгоритму, и "первый подходящий" к этому хешу пароль к фтп и панели не подойдет.) Да, ваш пост навел меня на мысль о схожей потенциальной уязвимости в DirectAdmin, на которую я попытаюсь обратить внимание разработчиков. Но просто, по сравнению с теми дырами в безопасности, которые существуют при бездумной эксплуатации CPanel, DirectAdmin (и наверное прочих панелей) "по-дефолту", это - мелочь.
А вот это правильно. Пишите лучше о том в чем вы разбираетесь не понаслышке.

А, я понял о чем Вы. Это Вы про Майкрософт пишите



Про VDS Вам уже говорили. А вот когда сломают VDS - Вы тоже будете говорить что Linux/FreeBSD недостаточно защищены?



Проблема решаема технически. А готовы ли Вы платить за такое решение?



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





У Вас - нет сервера, нет опыта. У нас - есть и то и другое, и о многом мы пишем "на халяву" - http://dedic.ru
Вам не стоит делать голословных категоричных заявлений среди тех, кто знаком с проблемной областью лучше Вас - выставляете себя не в лучшем свете.



Если "лишние файлы и папки" - это frontpage, то эта опция настраивается в WHM. Так же никто не мешает удалить эти ненужные файлы - в чем проблема?

Если есть желание высказаться по поводу безопасности виртуального хостинга, произвести анализ структуры скелета аккаунта cpanel и т.п. - добро пожаловать на dedic.ru
Только писать нужно не голословно а имея обоснования.



Не принимаю. Просто еще один очередной Ваш голословный выпад развеян...



Возможно. Я не хостер - а сисадмин. И мне часто приходилось восстанавливать сервера после взлома - причиной были уязвимые скрипты. Уязвимостью сервера взломщики не пользуются.
Или Вы хотите сказать что Ваши программы не содержат ошибок?




Не о ядре а о подходе к избавлению от ошибок. Если люди находят ошибку - пишут в багрепорт. Ошибка подтверждается - ее исправляют.
Вот точно так же и cPanel.



Первое - не общеизвестно. Укажите чем perl опаснее php.
frontpage - это технология от Майкрософт. Скажите им спасибо за это.



Я думаю, что хацкеры имеют более менее вменяемое представление об unix, им
это объяснять ненадо...


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



Кроме как к public_html по http доступа больше нет



1. Вы согласны с тем что по данному списку нельзя определить всех сервисов?
2. Я считаю что доступ к таким сведениям вполне нормален, ибо /etc/passwd есть публично читаемый файл. И взломщику его содержимое ничем не поможет.

To eSupport.org.ua:
Я своё мнение высказал ранее. А спорить не намерен.

ClayRabbit wrote: "Но реальность такова, что (в случае наиболее часто использующейся сейчас с CPanel модели обеспечения php-безопасности) файл .htpasswd с правами 644, помещенный в папку /home/user/public_html/dir/ находится в безопасности, а если вы поместите его в созданный вами /home/user/dir/ - его сможет прочитать любой пользователь сервера."
-- Вот в том то и дело, что модель "безопасности", которую избрали для сПанели, диктует эту самую реальность...
Разумеется, Вы вольны считать так, как считаете. И даже обвинять кого угодно в некомптентности суждений. Но и я тоже имею точно такие же права, особенно на форумах :)
ClayRabbit wrote: "потенциальной уязвимости в DirectAdmin, на которую я попытаюсь обратить внимание разработчиков"
-- Вот-вот... Желаю Вам удачи в этом деле.
Обвинять хостера у меня нет оснований. Ибо я сразу же исследовал ситуацию и пришел совершенно к определённым выводам, существенную для инет-общественности часть которых опубликовал в топике.
ClayRabbit, Вы случайно не причастны к разработке сПанели? :)

В ЗАКЛЮЧЕНИЕ. Краткие замечания:
1. Давно замечено: когда нечего сказать по существу вопроса, в публичных дискуссиях начинаются подначки и софистика. Как всё это старо и надоело!..
2. Если даже на "грошовом" шареде можно довольно легко залезть к "соседу" и почитать/переписать у него скрипты, это НИКАК нельзя считать нормальной практикой "безопасности", на которую можно де закрывать глаза!
3. Вот ведь какая "мудрая" и очень старая корпоративная политика наблюдается чуть ли не повсеместно в этом секторе услуг:
- "Взлом? - юзерские скрипты виноваты!"
- "Взлом через предустановленные скрипты-сервисы? - да, бывает, но изготовители патчат свои изделия!"
Заявление и обобщение это отнюдь не голословно. Ибо многие люди в интернете подмечали то же самое, не говоря о царящем и здесь таком же духе.
Вот хотя бы выборка извне навскидку:
Пример 1. Yurik wrote: "...хостеры факт что у них можно читать чужие файлы спихивают на то что а кто вам виноват что вы используете ПХП" - см. http://phpclub.ru/talk/showthread.php?post...5296#post315296 (пунктуация сохранена авторская).
Пример 2: ForJest wrote: "...Неведние выгодно хостерам в первую очередь. Типа - а вдруг пронесёт и к нам не пожалует тот самый военный программер. А так получается что на коленке пишут ламе... т.е. начинающие программисты для заказчиков, которые вообще ни сном не духом о возможных проблемах. А мы таки да продадим электричество, которое жрёт сервер за $2500 в месяц и будем счастливы..." (см. http://phpclub.ru/talk/showthread.php?post...6778#post316778 - цитата чуть подредактирована мною для внятности и связности мысли).
ТЕПЕРЬ О БОЛЕЕ СЕРЬЁЗНОМ И ВАЖНОМ.
Человеку думающему и знающему специфическую среду, представляющую собой Интернет, известны характерные приёмы, которыми пользуются хакеры. Тот специфический "дух" хакерства таким людям также хорошо знаком, что позволяет узнавать детали и решения, способные оказаться хакерскими (и потому потенциально или реально опасными для прочих в Интернет).
Вот например, ClayRabbit wrote: "...без safe_mode они ничего не гарантируют, разве что если все exec()-подобные функции начисто запретить. Но тогда еще симлинки останутся... Т.ч. safe_mode + safe_mode_exec_dir + в апаче запрещаем FollowSymLinks и оставляем только SymLinksIfOwnerMatch (При етом, к сожалению, приходится исключать Options из AllowOverride, что, в частности, ведет и к невозможности использовать в .htaccess php-директивы). А шо делать... Без этого можно чужие пхп-скрипты через симлинку апачем брать..." (см. http://phpclub.ru/talk/showthread.php?post...211#post321211), а далее оппонент спрашивает его: "Apache не может "утянуть" скрипт, он его может выполнить, что он и так постоянно делает. Для этого по линкам ходить не обязательно" (что само по себе конечно верно, комментирую я этот пассаж). Однако далее ClayRabbit отвечает на это оппоненту: "Да что вы говорите? В том и дело, что в большинстве случаев - запросто. Достаточно "RemoveType php" прописать в .htaccess - на своем, а симлинк - на чужой каталог (...) Еще надежнее - сделать симлинк не на папку, а сразу на файл (...) забудем про .htaccess Можно и без него. Выполните "ln -s /путь/к/чужому/файлу/config.php readme.txt" (Естественно на config.php должны стоять права 644, например.) И откройте readme.txt браузером c вашего сайта..." (см. серию постингов на http://phpclub.ru/talk/showthread.php?post...1627#post321627 и ....#post321634, ....#post321640, ....#post321646).
Для чего я привёл здесь этот диалог? Для того, чтобы показать "дух", присущий типичным хакерским приёмам...
А теперь посмотрим на "решение", которое применено и МАССОВО ТИРАЖИРУЕТСЯ разработчиками сПанели при открытии каждого эккаунта. Они вместо того, чтобы использовать СТАНДАРТНЫЕ средства конфигурирования Апачи, позволяющей иметь алиас на урл вида: www.sitename.ru (помимо чистого хоста sitename.ru), используют симлинк папки public_html как алиас "www" в домашней директории юзера на серваке... Чем не хакерское по духу (и непонятно, чего ради!) сомнительное "решение"... между прочим, имеющие серьёзные последствия и тянущее за собою и другие подобные же решения сомнительного свойства!
Или вот взять ещё технические детали, что доступны там же в ПХП-клубе:
fixxxer wrote: "Safe Mode - вполне себе решение проблем. Просто тут надо подходить с некоторой изобретательностью, а не тупо манипулируя On/Off-ами. Хотя, все решения уже общеизвестны и повсеместно используются..." (см. http://phpclub.ru/talk/showthread.php?post...789#post351789)
anight wrote: "Поправляю - не единственное. Проще и правильнее (imho) использовать apache2 + mod_fastcgi remote. MPM - perchild и кол-во запущенных apache для каждого VH должно совпадать с кол-вом запущенных php-fastcgi (разумеется с тем же uid/gid)..." (см. http://phpclub.ru/talk/showthread.php?post...759#post351759) "...по сравнению с преимуществами технологии - overhead можно вообще не учитывать. мне кажется php fastcgi будет всего на 0-10% медленнее mod_php." (см. http://phpclub.ru/talk/showthread.php?post...919#post351919).
С последними двумя утверждениями в этих постингах вполне можно согласиться, и грамотное использование таких средств, а не тех сомнительных тех. решений - это и есть правильный путь, не ведущий к уязвимостям...
Так вот, что я всем этим (и прочим в этой теме) хотел сказать.
Проблемы истинные начинаются там и тогда, если люди хотят совместить в одном месте и в одном решении несоединимое. Например, наивысшую призводительность со способностью и возможностю "исполнять всё" (чуть ли не любые юнкс-приложения*, а не спектр операций, предусмотренный _функциями языка_, и ограниченный возможностями и ЗАЩИТОЙ языков программирования). Да ещё и современной широкой доступностью на шаред-хостинге максимального числа сервисов, включая потенциально и даже реально опасные. А если ещё при этом легче лёгкого собрать информацию об индивидуальных особенностях данного хостера/сервера и об его клиентах, то о безопасности можно вообще забыть!.. (Любой хак начинается с исследования объекта!) И это - при явной целевой ориентированности всех шаредов на максимально публичный, след-но, и максимально уязвимый для вторжения сегмент интернет-доступа к данным!
Примечания:
* на мой взгляд, разрешать на шареде исполнять из перл/пхп скриптов что-то (особенно произвольное и непроверенное) из исполняемого юникс-кода - это означает открывать ворота настежь в своём доме... и если заказчику хоста и владельцу подобных скриптов нужны такие фишки - ему прямой путь, как минимум, на виртуальный дедик!.. (Моя реплика в скобках: а вот лицемерные попытки некоторых хостеров "выгнать" на дедик клиентов, требовательных к сохранности/приватности данных, - наглость и профессионональная несостоятельность!)
Вкратце резюмирую.
- В общем и целом, всё ОК!, - говорят (явно или косвенно) господа хостинг-провайдеры, особенно реселлеры. А вот "технари" разрабатывают решения, снимающие и для шареда известные проблемы, которые в основном связаны с погоней за высшей производительностью и "экономичностью" хостинга. (Потому что если таки не гнаться за выжимкой последних процентов производительности, то давно уже есть решения, вполне приемлемые всем.)
Беда в том, что скажем усовершенствования технологий, применимых в апачи или пхп, не означает автоматического продвижения этих решений в массы хостинг-провайдинга, тем более, с полной пользой. Ибо как управляющая надстройка над серверами и языками программирования (которые тоже конфигурируются) есть ещё "менеджер виртуальных хостов". От него, работающего фактически с правами (возможностями) админа сервера (имея полномочия делать... очень многое... во всех эккаунтах виртуального сервера, что вполне естественно), который и конфигурирует автоматически виртуальные хосты, многое на шареде как раз зависит. Именно от подобного автоматизированного администратора на самом деле очень и очень многое зависит - пожалуй, прежде всего предпосылки качества, устойчивости от взломов и робастности (чтобы не падал :) в эксплуатации всего данного хостинга.
А ведь решения эти зависят по большей части уже не от конкретного хостинг-провайдера, особенно "мелкого" (реселлера), которые едва ли смогут и будут "копаться" в купленном коммерческом ПО или даже более тщательно, со знаем и выдумкой, индивидуально конфигурировать оное, если надо, отходя от фирменной инструкции. След-но, они зависят... от всё тех же разработчиков, хотя бы той же сПанели!..
Но понимать и учитывать этого, похоже, в обозначенных кругах в упор не желают!..
Ну что ж, господа, пребывайте в подобной круговой поруке и недальновидности и далее.
Пользуясь случаем (ибо едва ли он представится мне ещё) выскажу также вот такое своё наблюдение.
Как раз в последние годы в связи с бурным развитием реселлерства наблюдается отвратительное явление: на сайтах этих хостинг-провайдеров чаще всего днём с огнём не найти достоверной и исчерпывающей информации об особенностях данного хостинга, настройках сервера, инструкции по использованию разрешенных сервисов, указания о том, что ЗДЕСЬ что-то принципиально запрещено, и всё прочее, что лет 10-6 назад составляло НЕПРЕМЕННЫЙ перечень информации, вывешиваемой на сайте любого хостинга. Это - признак неблагополучия и неуважения к своим будущим или случившимся клиентам, ведь подбирая хостинг клиент (если он не глубокий чайник!) естественно желает и должен узнать подобные особенности ДО* заказа хостинга! И это явление не случайное и единичное, а весьма массовое (в этом сегменте рынка). И оно косвенно, а может быть и системно, "идеологически" навязано "автоматизаторами" типа фирм-разработчиков сПанели и иже с ними... (Через политику ведения подсистемы "Помощь".)
* примечание: иначе не может не реализоваться по полной программе юзерский "афоризм" - "Выбор хостинга - это также как выбор жены: до свадьбы она одна, после свадьбы - другая..." %;=)))
И в заключение. Здесь в топике и на протяжении темы я более чем достаточно (конечно для умеющего и желающего думать непредвзято) сказал откровенно и публично. Но когда "не внемлют и не разумееют"... Что ж, отряхнув прах со ступней ног, закрываю дверь с наружной стороны.

Предложите свою - на базе mod_php...


Правильно. Берите VDS, а еще лучше выделенный сервер.



Расходы для предоставления отдельного апача под пользователя на порядок выше чем общий апач.
Так же как и работа php в cgi режиме грузит сервер сильнее чем mod_php.
А платить 20-30$ за отдельный апач если на эти деньги можно взять VDS - глупо!



Когда кажется - креститься надо. Если взять обычный дуальный ксеон с 2-я гигами памяти который поддерживает без перегрузки 250 аккаунтов (со всякими php нюками в т.ч.), то cpu usage by user скакнет под 99% и все будет тормозить.


Наоборот - если Вам неподходит ширпотреб в виде виртуального хостинга - то Вам путь на VDS или на реальный дедик.
Большинству вполне хватает обычного виртуалхостинга. А равняются - по большинству.



Решение есть и имя ему - VDS. Остальное - не даст такой защиты.


Можете взять хостинг где все выполняется вручную, afaik это в мастерхосте, зеноне. В чем проблема?


А никому эта информация ненужна. Более того, она ненужна и владельцам выделенных серверов, они берут сервера для конкретных вещей - чтоб "форум работал", а как это реализовано - им не интересно.
Не у каждого есть желание изучать новую и ненужную ему информацию



Вы не из Одессы? А то у нас так принято - говорить "досвиданья" и возвращаться

Кстати если поискать можно найти и тех у кого отдельный апач будет и за 5$.
Например мы так практиуем, и знаю что другие тоже есть!

Эту модель избрали хостеры, которых не устраивает уровень безопасности который "обеспечивает" CPanel "по-дефолту". Эта модель - оптимальное решение, в условиях использования CPanel.
Т.е. вы оставляете за своим хостером право установить на сервере какую-нить фигню, и при этом не думать о том, к каким проблемам это может привести, и не нести за них ответственность? Эх, нам бы таких лояльных клиентов. Чуть что - так это вина разработчиков, а мы-то, мы конечно не виноваты, что выбираем ненадежное ПО, а повысить его надежность у нас не хватает мозгов
Нет. Более того, мы отказались от ее использования на новых серверах 2 года назад.
С этим кто-то спорит? Предотвратить это - в силах любого хостера, было бы желание.
Насмешили... Вы услышали новое слово "симлинк" в контексте взлома, и теперь везде где вы симлинки увидете вам хакеры будут мерещиться? Это, простите, клиника...
(И, кстати, эта очередная ваша фантазия на тему "как это решено в CPanel" не имеет с действительностью ничего общего. Это факт. Потому как там именно обыкновенный алиас, а симлинк упомянутый вами ни для чего не используется.)
А мне вот почему-то всегда казалось, что безопасность сервера зависела и зависит прежде всего от администратора этого сервера. Почему вы думаете, что какая-то CPanel может его заменить и должна вместо него нести ответственность за ненадежность системы - мне неясно. Первый раз сталкиваюсь такой точкой зрения.

В то время как за 4.95 можно взять VDS...

еще раз повторю что мне непонятно направленность темы. у любого продукта есть свои недостатки и спанель не исключение. выбор спанели в качестве оболочки для управления хостингом определен исторически, грамотным маркетингом и спросом.
есть хостеры которые все делают сами в том числе и разрабатывают эту оболочки и необязательно это монстры. но, все равно у всякого комплексного решения есть свои недостатки.
к тому же чем сложнее продукт тем сложнее его перелопатить. вот вы знаете к примеру что фактически спанель выросла из вебмина? нет наверное, а ведь вебмин и до сих пор устанавливается и что то не уменьшается число его пользователей.
Существенно уменьшить количество проблем можно было бы использованием хотя бы chroot, но даже это не используется во всех распространенных контрольных панелях. Я не готов думать о разработчиках хуже чем о себе и подозреваю что если Cpanel, Directadmin, Swsoft, Psoft (в составе двух последних большая часть разработчиков - русскоязычные люди и как правило неплохие программисты) до сих пор не приняли даже эту модель, значит это не просто так и для массового распространения/использования не подходит.
В то же время, никто не мешает администраторам самим доработать под себя как саму спанель, так и настроить сервер так, чтобы компромисс между функциональными возможностями и защищенностью был оптимален. Компромисс к сожалению всегда будет. Даже тот же chroot/jail не гарантирует безопасности, поскольку все равно это не полная виртуализация/изоляция аккаунта пользователя и ее хоть и намного сложнее, но тем не менее возможно обойти теретически.

ВСЕМ: изголяться же в "остроумии" и/или пререкатья с сим обчеством, переливая из пустого в порожнее, не имею ни желания, ни времени...

Но он используется, насколько понимаю, из экономии, или на дешевых/маломощных ВДС, в связи с тем, что слабый ВДС не каждую панель потянет. Или я ошибаюсь?

А vds можно и ручками админить через консоль...

Ошибаетесь. Webmin работает на перле и вроде на питоне, которые не являются ресурсосберегающими технологиями, особенно в памяти.

Ставят т.к.
1. Бесплатно.
2. Ставится на большом количестве os и имеет богатую историю развития.
3. Ставится из rpm/deb , и даже доступно в рамках дистрибутива часто (yum, up2date, apt-get) что позволяет поставить даже на очень маломощных vps (другое дело что запустить может и не удастся )

Я против устоявшейся фразы - панель потребляет, не потянет эту панель...

1. Панель сама по себе потребляет мало ресурсов, только если встроенный web сервер и небольшие фичи типа logdaemon у cpanel. Остальное - сервисы, которые ставятся этой панелью автоматически, такие как apache, mysql, почтовый сервер и т.д. Вот они то и тратят ресурсы. Если Вы сами делаете систему руками, то Вы можете поставить именно то что Вам нужно и ни цента больше. А панель ставит стандартный набор, который Вам может и не нужен в полном объеме.

2. Есть панели (пожалуй меньшинство), которые ставятся из готовых пакетов для конкретных дистрибутивов - rpm`ами например. Это webmin, plesk, ispmanager прежде всего. Поэтому они ставятся очень просто и шустро. Как и во всем, тут есть свои плюсы и минусы. Есть же панели, которые многое компилируют из сорсов, это cPanel, DirectAdmin и другие. Сама эта компиляция требует немалых ресурсов как по cpu так и по памяти. Получается, что такую систему на 128 Мб памяти ну никак не прикрутить.

to moders: Наверно лучше, если это выделить отдельной темой.

БОЛЬШОЕ спасибо, что пояснили



Точно, тем более что человек любезно согласился объяснить особенности webmin и cpanel, сравнив их
http://forum.hostobzor.ru/index.php?s=&...ost&p=48630
- вполне достойно того, чтобы вытащить то, что касается webmin, в отдельную тему, пока он не передумал