- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
У вас же нет ничего, что вы могли бы предложить, кроме ssh. А это нужно лишь какерам.
И всем достаточно хорошо подготовленным пользователям.
Ну, во-первых, CGI-скрипты - это совсем не то же, что шелл.
Если есть доступ к своим CGI и разрешено выполнение своих бинарных файлов то запустить свой sshd слушать верхний порт с правами своего пользователя это дело нескольких минут, если есть доступ к своим CGI и разрешено выполнение только скриптов но запрещено выполнение своих бинарных файлов то без подготовки немного дольше, кстати логить системный sshd как предлагал один из ораторов раньше бесполезно по этой же причине.
Ну, во-первых, 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, а в том, какой должен быть необходимый минимум чтобы клиент пошел к нам.
кроме того, есть .bash_history, можно там свериться.
а что мешает удалить .bash_history и cоздать пустой ?
Если есть доступ к своим CGI и разрешено выполнение своих бинарных файлов то запустить свой sshd слушать верхний порт с правами своего пользователя это дело нескольких минут.
Гм, sshd запустить не выйдет по двум причинам:
1. у Вас прав к /etc/shadow нет, чтобы пароли сравнивать.
2. никто Вам без прав рута tty не откроет.
единственный способ запускать на нервивелегированном порту bash -i, только это с успехом закрывается файерволом.
а что мешает удалить .bash_history и cоздать пустой?
Лучше сразу логить на /dev/null
Если после грязных дел history просто удалять то как раз перед удалением может быть например архивирование файловой системы, файл может быть открыт каким нибудь другим процессом и сохраниться пока работает тот процесс, и вообще у файла может быть много hard links так что можно название файла удалить а сам файл останется.
Вы незаметно ушли в обсуждение совсем другого вопроса - можно ли сломать систему через пользовательский шелл? Можно, разумеется, и можно сломать систему вообще без шелла. Не говоря уже о возможности банально остановить любой системный логгер :).
Честно говоря, не вижу описания проблем. У одного письмо пропало, у другого авторизация не сразу проходит - и это все?! Это вот серьезные проблемы у крупнейшего рунетовского хостера?
Ну и? Это, собственно, не есть проблема вообще. Если стандартный способ взаимодействия с файлом - через скрипт, то зачем туда руками лезть?
Вот чудаки. Ну да, в этом и вопрос - чем вы привлечете клиента. Пока видны два "преимущества" - шелл и низкие цены. Если на них не придет толпа script-kiddies, то вам повезло.
Гм, sshd запустить не выйдет по двум причинам:
1. у Вас прав к /etc/shadow нет, чтобы пароли сравнивать.
2. никто Вам без прав рута tty не откроет.
Я сразу написал свой sshd причем на верхнем порту то есть надо его самому скомпилировать со всеми путями на каталог пользователя и положить там свои системные файлы типа как это делается при chroot а tty системный опять же не нужен потому что на верхнем порту можно сделать все свое.
единственный способ запускать на нервивелегированном порту bash -i, только это с успехом закрывается файерволом.
Вы закроете входящие соединения а канал можно сделать и в обратную сторону, я очень сомневаюсь что Ваш хостинг будет кому то полезен без возможности например проверять обратные линки.
Вы незаметно ушли в обсуждение совсем другого вопроса - можно ли сломать систему через пользовательский шелл? Можно, разумеется, и можно сломать систему вообще без шелла. Не говоря уже о возможности банально остановить любой системный логгер :).
Ну изначально Вы говорили, что shell - дыра в безопасности, отсюда все и растет, а по сути что cgi что shell - разницы _практически_ никакой, только в первом случае работать куда удобнее, по крайней мере продвинотому клиенту, а если кто-то серьезно решил сломать систему, то ему все равно что есть cgi или shell.
Честно говоря, не вижу описания проблем. У одного письмо пропало, у другого авторизация не сразу проходит - и это все?! Это вот серьезные проблемы у крупнейшего рунетовского хостера?
у Seliger тоже иногда не все в порядке ...
Ну и? Это, собственно, не есть проблема вообще. Если стандартный способ взаимодействия с файлом - через скрипт, то зачем туда руками лезть?
например сессии, зааплоаженные файлы удалить. Вся это возня с выставлением соответствующих прав в случае с mod_php по сути одна большая дыра, например разрешили куда-либо писать апачу, соответственно туда злоумышленник может свой код залить, и дело тут не в том что кого-либо сломают через phpbb (тут уж клиент сам себе злобный буратино), а в том, что от этого могут пострадать другие сайты, расположенные на сервере.
Вот чудаки. Ну да, в этом и вопрос - чем вы привлечете клиента. Пока видны два "преимущества" - шелл и низкие цены. Если на них не придет толпа script-kiddies, то вам повезло.
Угу, может кто-нибудь подскажет как привлечь-то ?
Я сразу написал свой sshd причем на верхнем порту то есть надо его самому скомпилировать со всеми путями на каталог пользователя и положить там свои системные файлы типа как это делается при chroot а tty системный опять же не нужен потому что на верхнем порту можно сделать все свое.
прав не хватит, вот цитата из man'а:
If the client successfully authenticates itself, a dialog for preparing the session is entered. At this time the client may request things like allocating a pseudo-tty, forwarding X11 connections, forwarding TCP/IP connections, or forwarding the authentication agent connection over the secure channel.
то есть если нет прав на открытие tty, то полноценный bash запустить нельзя, только interactive
An interactive shell is one started without non-option arguments and without the -c option whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option. PS1 is set and $- includes i if bash is interactive, allowing a shell script or a startup file to test this state.
про файервол согласен.