- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
у reg.ru с регистрацией тоже не все гладко. в частности там, где они не регистратор, а реселлер регистратора. не забуду, как домен .de, зарегистрированный через них, через несколько месяцев оказался удален без уведомлений и адекватных пояснений. с тех пор они закрыли регистрацию в этой зоне.
Когда клиент сам виноват (взломали его сайт из-за дырки в скриптах) - это одно. А когда взломали весь сервер (даже из-за дырки в сайтах одного клиента) - другое.
Безусловно! И каждый из случаев нужно тщательно контролировать и проверять. Но если говорить обобщенно то взлом сайта это уже никак не "нормально" :) Это может быть в худшей степени или в обычной, но никак не в норме, так-же как и по вине хостера или клиента :)
Но если говорить обобщенно то взлом сайта это уже никак не "нормально" :) Это может быть в худшей степени или в обычной, но никак не в норме, так-же как и по вине хостера или клиента :)
Если хостер установил дополнительную защиту для предотвращения взлома сайтов через известные дыры в движках, плюс поставил еще несколько плюшек, что бы хакерский софт не работал будучи загруженным на аккаунт или вообще предотвращал такую загрузку, но это удалось обойти (обычных школохацкеров это останавливает), то вины хостера тут нет, т.к. он сделал все для общей защиты сайтов.
Но, если взломан весь сервер через клиентский аккаунт, то это прямая вина хостера. Не думаю что сервак регру ломал матерый исследователь в области безопасности через наиновейшую дыру в какой нить библиотеке, про которую даже разработчикам не известно. Они такой ерундой не занимаются, следовательно это делал школоло через старые дыры в софте или заведомо небезопасной настройке сервера. Чего тут и говорить, грош цена тому аникейщику который настраивал этот сервак.
об том и речь что это не вина хостера. рута получить не смогут в большинстве случаев а покрошить юзерам индексные файлы - запросто. это связано с особенностями организации виртуального хостинга на спанели, директадмине, испманагере, хсфере, плеск и т.п. так как полного разделения между аккаунтами без принятия специальных мер (например без выделения для каждого аккаунта своего апача или среды окружения) не существует пока что.
а покрошить юзерам индексные файлы - запросто.
Это каким же образом? Допустим, стандартная настройка httpd работает от nobody + suEXEC + suPHP. Все обновлено до последних стабильных версий.
Как можно получить доступ к другому аккаунту хотя бы на чтение?
а кто сказал что у них suphp? и эта связка работает предсказуемо для пхп а для перл скрипта запущенного из /tmp она не сработает (даже если засекурен /tmp).
а кто сказал что у них suphp? и эта связка работает предсказуемо для пхп а для перл скрипта запущенного из /tmp она не сработает (даже если засекурен /tmp).
Запуск perl из tmp да и любого бинарника отключается очень просто.
P.S.
А действительно, какая панель была у них?
P.P.S.
и что-то я совсем не верю, что запущенный perl скрипт из temp каким-то образом обойдет систему привилегий linux.
Не думаю что сервак регру ломал матерый исследователь в области безопасности через наиновейшую дыру в какой нить библиотеке, про которую даже разработчикам не известно. Они такой ерундой не занимаются, следовательно это делал школоло через старые дыры в софте или заведомо небезопасной настройке сервера. Чего тут и говорить, грош цена тому аникейщику который настраивал этот сервак.
Вы прежде чем считать себя самым умным, рассказывать кто чем занимается, и навешивать ярлыки, посчитайте сколько в libc было критичных фиксов только за этот год.
hvosting, были "эпидемии" по этому поводу из-за libc и повальный вынос серверов? Не припоминаю таких новостей.
hvosting, были "эпидемии" по этому поводу из-за libc и повальный вынос серверов? Не припоминаю таких новостей.
Видимо не там или не те новости читаете.
Были и уязвимости и рабочие эксплойты.
Хотя конечно - назвать не самого мелкого хостера эникейщиком! Настолько повышает ЧСВ...