ДОПОЛНЕНИЕ 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: "кончили глобальными проблемами"
-- тем, кто презирает решение "глабальных проблем", всю оставшуюся жизни придётся ловить массово расплодившихся жуков... и крыс ;-))))

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