ДОПОЛНЕНИЕ 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 доступа больше нет