Как писал Gray Вы незаметно ушли в обсуждение совсем другого вопроса - можно ли сломать систему через пользовательский шелл? Можно, разумеется, и можно сломать систему вообще без шелла. Не говоря уже о возможности банально остановить любой системный логгер :).
Ну изначально Вы говорили, что shell - дыра в безопасности, отсюда все и растет, а по сути что cgi что shell - разницы _практически_ никакой, только в первом случае работать куда удобнее, по крайней мере продвинотому клиенту, а если кто-то серьезно решил сломать систему, то ему все равно что есть cgi или shell.
Как писал Gray Честно говоря, не вижу описания проблем. У одного письмо пропало, у другого авторизация не сразу проходит - и это все?! Это вот серьезные проблемы у крупнейшего рунетовского хостера?
у Seliger тоже иногда не все в порядке ...
Как писал Gray Ну и? Это, собственно, не есть проблема вообще. Если стандартный способ взаимодействия с файлом - через скрипт, то зачем туда руками лезть?
например сессии, зааплоаженные файлы удалить. Вся это возня с выставлением соответствующих прав в случае с mod_php по сути одна большая дыра, например разрешили куда-либо писать апачу, соответственно туда злоумышленник может свой код залить, и дело тут не в том что кого-либо сломают через phpbb (тут уж клиент сам себе злобный буратино), а в том, что от этого могут пострадать другие сайты, расположенные на сервере.
Как писал Gray Вот чудаки. Ну да, в этом и вопрос - чем вы привлечете клиента. Пока видны два "преимущества" - шелл и низкие цены. Если на них не придет толпа script-kiddies, то вам повезло.
Если есть доступ к своим CGI и разрешено выполнение своих бинарных файлов то запустить свой sshd слушать верхний порт с правами своего пользователя это дело нескольких минут.
Гм, sshd запустить не выйдет по двум причинам:
1. у Вас прав к /etc/shadow нет, чтобы пароли сравнивать.
2. никто Вам без прав рута tty не откроет.
единственный способ запускать на нервивелегированном порту bash -i, только это с успехом закрывается файерволом.
Как писал Gray Ну, во-первых, CGI-скрипты - это совсем не то же, что шелл. Во-вторых, вести логи сессий пользователей просто бессмысленно - все, что надо, зафиксирует обычный логгер, кроме того, есть .bash_history, можно там свериться.
разница между cgi и shell отличается только в наличии контролирующего терминала в последнем, то есть если существует какой-либо exploit позволяющий запустить рутовый shell, то в первом случае он не запустится, правда это не меняет положения дел, всегда можно заменить в shellcode вызов /bin/sh на что-нибудь другое. Про .bash_history не совсем правда, можно просто сделать export HISTFILE=/dev/null, и тогда никакие логи оставаться в истории не будут, можно конечно сделать restricted shell и пр, но тогда возникает такой вопрос: а нужен ли кому такой shell ?
Как писал Gray Вы очень смело заявляете об этом - вы действительно готовы приводить факты наличия на Мастерхосте проблем с почтой и php?
с mod_php много у кого возникают проблемы, точнее она одна но большая, как известно php-скрипты запускаются из-под apache и не из-под обычного пользователя, соответсвенно вот что получается:
1. файлы созданные при помощи скриптов нельзя удалить/изменить через shell/ftp, поскольку у файлов стоит оунер apache, это конечно решается некоторыми способами (например выставлять в скриптах umask, самому в скриптах дописывать chmod, но тогда клиенту приходится уже самому ковыряться; или например вот солюшн от .m: http://masterhost.ru/support/doc/php/#compile , только при этом теряется скорость и некоторые вкусности)
2. по соображениям безопасности в php приходится отключать ряд функций (конкретно весь класс exec-функций, плюс еще некоторые, в том же .m это написано: http://masterhost.ru/support/doc/php/#limitations) после чего некоторые бесплатные движки перестают работать.
Как писал Gray Этой сотне надо популярно объяснить - почему они должны предпочесть не надежного, зарекомендовавшего себя, лидера индустрии, а кустарный сервис, размещенный на той же площадке.
Еще раз повторюсь, мы сейчас даже не задумывается о таких масштабах как .m. Вопрос не в том как стать такими же как .m, а в том, какой должен быть необходимый минимум чтобы клиент пошел к нам.
Как писал Gray А чем ваш ненагруженный сервер отличается от такого же, принадлежащего Мастерхосту - кроме того, что у МХ обученный круглосуточный саппорт и вся инфраструктура?
отсутствием проблем с почтой, отсутсвием проблем с php, если нужно про qmail и mod_php могу подробно изложить свое мнение. К тому же, мы не ориентируемся на .m, на начальном этапе нам не нужны тысячи клиентов, тут бы до сотни не плохо было бы дотянуть.
Как писал Gray Чушь говорите.
SkyNet, в вашем случае шелл - это большая дыра в безопасности.
Если честно, я принципиальной разницы между разрешением запуска cgi-скриптов и предоставлением shell не вижу, в конце концов, можно немного поправить sshd, чтобы все вводимые команды логировались.
Как писал absolut Привлечь к чему? У вас же нет ничего, что вы могли бы предложить, кроме ssh. А это нужно лишь какерам.
ну почему-же, есть _ненагруженный_ сервер, пара человек, некисло знающих апач и пару языков, которые по началу будут выполнять функции саппорта. А что можно предложить кроме стандартных сервисов (http, smtp, pop, imap, dns, ftp) ?
думаю, нам излишнии навороты типа уснавки форумов из панели и пр. не нужны, вполне будет достаточно управления почтой, dns и виртуал хостов, для всего остального у клиента будет шелл.
Вы незаметно ушли в обсуждение совсем другого вопроса - можно ли сломать систему через пользовательский шелл? Можно, разумеется, и можно сломать систему вообще без шелла. Не говоря уже о возможности банально остановить любой системный логгер :).
Ну изначально Вы говорили, что shell - дыра в безопасности, отсюда все и растет, а по сути что cgi что shell - разницы _практически_ никакой, только в первом случае работать куда удобнее, по крайней мере продвинотому клиенту, а если кто-то серьезно решил сломать систему, то ему все равно что есть cgi или shell.
Честно говоря, не вижу описания проблем. У одного письмо пропало, у другого авторизация не сразу проходит - и это все?! Это вот серьезные проблемы у крупнейшего рунетовского хостера?
у Seliger тоже иногда не все в порядке ...
Ну и? Это, собственно, не есть проблема вообще. Если стандартный способ взаимодействия с файлом - через скрипт, то зачем туда руками лезть?
например сессии, зааплоаженные файлы удалить. Вся это возня с выставлением соответствующих прав в случае с mod_php по сути одна большая дыра, например разрешили куда-либо писать апачу, соответственно туда злоумышленник может свой код залить, и дело тут не в том что кого-либо сломают через phpbb (тут уж клиент сам себе злобный буратино), а в том, что от этого могут пострадать другие сайты, расположенные на сервере.
Вот чудаки. Ну да, в этом и вопрос - чем вы привлечете клиента. Пока видны два "преимущества" - шелл и низкие цены. Если на них не придет толпа script-kiddies, то вам повезло.
Угу, может кто-нибудь подскажет как привлечь-то ?
Если есть доступ к своим CGI и разрешено выполнение своих бинарных файлов то запустить свой sshd слушать верхний порт с правами своего пользователя это дело нескольких минут.
Гм, sshd запустить не выйдет по двум причинам:
1. у Вас прав к /etc/shadow нет, чтобы пароли сравнивать.
2. никто Вам без прав рута tty не откроет.
единственный способ запускать на нервивелегированном порту bash -i, только это с успехом закрывается файерволом.
Ну, во-первых, CGI-скрипты - это совсем не то же, что шелл. Во-вторых, вести логи сессий пользователей просто бессмысленно - все, что надо, зафиксирует обычный логгер, кроме того, есть .bash_history, можно там свериться.
разница между cgi и shell отличается только в наличии контролирующего терминала в последнем, то есть если существует какой-либо exploit позволяющий запустить рутовый shell, то в первом случае он не запустится, правда это не меняет положения дел, всегда можно заменить в shellcode вызов /bin/sh на что-нибудь другое. Про .bash_history не совсем правда, можно просто сделать export HISTFILE=/dev/null, и тогда никакие логи оставаться в истории не будут, можно конечно сделать restricted shell и пр, но тогда возникает такой вопрос: а нужен ли кому такой shell ?
Вы очень смело заявляете об этом - вы действительно готовы приводить факты наличия на Мастерхосте проблем с почтой и php?
про почту как всегда яндекс:
http://earnforum.com/vb/printthread.php?threadid=33224
http://www.hostinfo.ru/forum/posting.php?mode=topicreview&t=254&sid=5dd836feb59cf93ce8147d77d757b7e3
http://fotonovosti.ru/forum/posting.php?mode=quote&p=324&sid=d13acde157421e050ae0e368869c37b1
с mod_php много у кого возникают проблемы, точнее она одна но большая, как известно php-скрипты запускаются из-под apache и не из-под обычного пользователя, соответсвенно вот что получается:
1. файлы созданные при помощи скриптов нельзя удалить/изменить через shell/ftp, поскольку у файлов стоит оунер apache, это конечно решается некоторыми способами (например выставлять в скриптах umask, самому в скриптах дописывать chmod, но тогда клиенту приходится уже самому ковыряться; или например вот солюшн от .m: http://masterhost.ru/support/doc/php/#compile , только при этом теряется скорость и некоторые вкусности)
2. по соображениям безопасности в php приходится отключать ряд функций (конкретно весь класс exec-функций, плюс еще некоторые, в том же .m это написано: http://masterhost.ru/support/doc/php/#limitations) после чего некоторые бесплатные движки перестают работать.
вроде тут все разжевано про апач: http://phpclub.ru/talk/showthread.php?threadid=47772&rand=92
Этой сотне надо популярно объяснить - почему они должны предпочесть не надежного, зарекомендовавшего себя, лидера индустрии, а кустарный сервис, размещенный на той же площадке.
Еще раз повторюсь, мы сейчас даже не задумывается о таких масштабах как .m. Вопрос не в том как стать такими же как .m, а в том, какой должен быть необходимый минимум чтобы клиент пошел к нам.
А систему Unix они как знают?
опыт 5 лет.
А чем ваш ненагруженный сервер отличается от такого же, принадлежащего Мастерхосту - кроме того, что у МХ обученный круглосуточный саппорт и вся инфраструктура?
отсутствием проблем с почтой, отсутсвием проблем с php, если нужно про qmail и mod_php могу подробно изложить свое мнение. К тому же, мы не ориентируемся на .m, на начальном этапе нам не нужны тысячи клиентов, тут бы до сотни не плохо было бы дотянуть.
Настоятельно рекомендую сначала изучить систему, а потом продавать свои услуги, с ней связанные. Поможет не делать ляпов на публике.
про ляпы, если можно поподорбнее расскажите :)
Чушь говорите.
SkyNet, в вашем случае шелл - это большая дыра в безопасности.
Если честно, я принципиальной разницы между разрешением запуска cgi-скриптов и предоставлением shell не вижу, в конце концов, можно немного поправить sshd, чтобы все вводимые команды логировались.
Привлечь к чему? У вас же нет ничего, что вы могли бы предложить, кроме ssh. А это нужно лишь какерам.
ну почему-же, есть _ненагруженный_ сервер, пара человек, некисло знающих апач и пару языков, которые по началу будут выполнять функции саппорта. А что можно предложить кроме стандартных сервисов (http, smtp, pop, imap, dns, ftp) ?
думаю, нам излишнии навороты типа уснавки форумов из панели и пр. не нужны, вполне будет достаточно управления почтой, dns и виртуал хостов, для всего остального у клиента будет шелл.