Comments 84
Для исследования были выбраны случайным образом 30 000 действующих сайтов в домене RU, созданные на различных CMS.
доли всех CMS в этой выборке были одинаковы?
Доли были одинаковы, конечно. На первом графике — это доля в общем числе зараженный сайтов, а не общий процент зараженных на конкретной CMS.
Достаточно «сферическое» тестирование, «в сильно разреженной атмосфере», если вы понимаете о чем я.
Поясню, почему я так утверждаю…
Зараженность тех или иных сайтов на определенной CMS определяется очень разными факторами, многие из них взаимосвязаны (о некоторых вы не упомянули):
— возраст CMS (условно говоря как долго она на рынке), т.к. этот фактор влияет с одной стороны на опыт и количество разработчиков, с другой стороны (что существенней) на распределение версий (в том числе старых и глючных) в общем количестве.
— технологиями которые используются в CMS. Т.к. некоторые требуют определенных библиотек или мощностей сервера, а соответственно распределение по шаред-хостингам / ВПС / частным серверам.
— распространенность CMS в целом. Тут трудно однозначно сказать в какую сторону и как влияет, но скорее чем популярнее тем в среднем надежнее — см. п.1 про возраст системы и количество разработчиков.
— сильно зависит от инфраструктуры самой CMS. Т.е. упрощая от того на сколько просто накатить последние оф. обновления (тут опять смотри на пункт про фрагментацию версий внутри одной CMS).
Помимо прочего не понятно как определялись версии CMS, т.к. далеко не все выдают это в открытом виде (но о корректности определения написали ниже).
Bот что еще важно, на мой взгляд: то, что платные CMS оказались менее уязвимы (почти) никак не говорит о том, что они безопаснее или о профессионализме разработчиков. Просто платными пользуются те, кто может себе позволить, т.е. спецы и конторы которые готовы за свой сайт платить, а это сказывается и на уровне отдельного хостинга, и как правило наличии выделенных специалистов (админах сервера, админах CMS) и т.д. Отсюда и средний уровень безопасности инфраструктуры на порядок выше.
Поясню, почему я так утверждаю…
Зараженность тех или иных сайтов на определенной CMS определяется очень разными факторами, многие из них взаимосвязаны (о некоторых вы не упомянули):
— возраст CMS (условно говоря как долго она на рынке), т.к. этот фактор влияет с одной стороны на опыт и количество разработчиков, с другой стороны (что существенней) на распределение версий (в том числе старых и глючных) в общем количестве.
— технологиями которые используются в CMS. Т.к. некоторые требуют определенных библиотек или мощностей сервера, а соответственно распределение по шаред-хостингам / ВПС / частным серверам.
— распространенность CMS в целом. Тут трудно однозначно сказать в какую сторону и как влияет, но скорее чем популярнее тем в среднем надежнее — см. п.1 про возраст системы и количество разработчиков.
— сильно зависит от инфраструктуры самой CMS. Т.е. упрощая от того на сколько просто накатить последние оф. обновления (тут опять смотри на пункт про фрагментацию версий внутри одной CMS).
Помимо прочего не понятно как определялись версии CMS, т.к. далеко не все выдают это в открытом виде (но о корректности определения написали ниже).
Bот что еще важно, на мой взгляд: то, что платные CMS оказались менее уязвимы (почти) никак не говорит о том, что они безопаснее или о профессионализме разработчиков. Просто платными пользуются те, кто может себе позволить, т.е. спецы и конторы которые готовы за свой сайт платить, а это сказывается и на уровне отдельного хостинга, и как правило наличии выделенных специалистов (админах сервера, админах CMS) и т.д. Отсюда и средний уровень безопасности инфраструктуры на порядок выше.
Для исследования были выбраны случайным образом 30 000 действующих сайтов в домене RU
Надеюсь, количество сайтов на каждой из представленных CMS в выборке было примерно одинаковым? После процитированной фразы закрадываются сомнения. Просто процентное соотношение бралось от общего числа сайтов, и при таком раскладе это очень важный момент.
PS: я обновлял страницу перед отправкой комментария, там ничего было…
Не совсем понятно что за проценты: процент зараженных сайтов из 30К или процент зараженных сайтов из всех сайтов на данной CMS?
Меня ОЧЕНЬ смущает то, что никакого реального анализа угроз авторами не было проведено: есть вирус по данным «Васи Пупкина» — считаем. Ложнопозитивные и ложнонегативные результаты могли бы ОЧЕНЬ сильно изменить статистику, особенно первые.
Меня ОЧЕНЬ смущает то, что никакого реального анализа угроз авторами не было проведено: есть вирус по данным «Васи Пупкина» — считаем. Ложнопозитивные и ложнонегативные результаты могли бы ОЧЕНЬ сильно изменить статистику, особенно первые.
Легенда возле графиков нечитаемая вообще.
Не только легенда — первая диаграма содержит всего три цвета с небольшими оттенками в ту или иную сторону. Такое впечатление, что это такой специальный тест для дальтоников
Коллеги, да, с цветами не очень вышло. Но на основной странице исследования www.ruward.ru/sitesecure/ графики интерактивны — там смотреть проще…
Я пипеткой тыкал. Иначе не разобрать
Интересно было бы узнать, как технически определялась CMS конкретного сайта? Как мне кажется, парсингом HTML?
Составить выборку нам помогли коллеги из iTrack, у них есть специальный сервис: itrack.ru/whatcms/
Судя по тому, что на введённом для примера самописном сайте он нашёл NetCat, я бы ему не стал сильно доверять.
А на demo.advantshop.net не нашел AdvantShop.Net, хотя в списке у них эта CMS представлена.
RBC Contents не смог определить, хотя у них есть эта CMS.
Разработчиков CMS как-то оповещали об обнаруженных проблемах?
Так исторически сложилось, что на одном из моих сайтов стоит Datalife Engine (лицензия), которую периодически взламывают, каждый раз через 3-5 месяцев после релиза. При этом дыры я закрываю, безопасность соблюдаю, обновляюсь регулярно.
Так исторически сложилось, что на одном из моих сайтов стоит Datalife Engine (лицензия), которую периодически взламывают, каждый раз через 3-5 месяцев после релиза. При этом дыры я закрываю, безопасность соблюдаю, обновляюсь регулярно.
Как-то подозрительно отсутствие Друпала в списке популярных CMS
Видимо, не нашли зараженных экземпляров. Либо с выборкой не повезло, друпал должен быть по сути.
Всё просто! В Друпале (в отличие от других систем), настолько железобетонная защита, что его просто невозможно заразить )))
Поэтому он даже в отчет не попал.
Поэтому он даже в отчет не попал.
Как и ещё более 39 CMS из известных itrack'у
Да уж… У него только успевай обновляться — пекут security patches, как пирожки
По результатам исследования сайты, использующие, бесплатные CMS в среднем в четыре раза чаще подвергаются заражениями и попадают в черные списки, чем сайты на коммерческих CMS.'
Из первой диаграммы неосведомленному человеку понять кто из представленных CMS бесплатный, а кто нет — невозможно.
Связано ли то, что сайты на бесплатных CMS подвергаются заражению чаще, чем сайты на платных CMS с тем, что сайтов на бесплатных CMS больше, чем на платных? Без указания количества сайтов по каждой из CMS в выборке и отдельных диаграмм для платных и бесплатных CMS все диаграммы в статье доверия не вызывают.
Я считаю не совсем корректно делать такой анализ, логика проста: надежность сайта напрямую зависит от квалицикации разработчика его создавшего, от того как настроен сам вебсервер, от того как оперативно обновляется CMS на конкретном сайте, от того сколько сторонних модулей было установлено или написано для сайта и каково качество их кода.
Ибо сайты сделанные по принципе фриланс => фрилансер с опытом несколько месяцев => joomla => +20 сторонних модулей => сдача проекта => забыли на год 100% приводит к образовыванию в сайте огромного количества дыр и врятли тут всю ответсвенность можно возможить на cms.
Ибо сайты сделанные по принципе фриланс => фрилансер с опытом несколько месяцев => joomla => +20 сторонних модулей => сдача проекта => забыли на год 100% приводит к образовыванию в сайте огромного количества дыр и врятли тут всю ответсвенность можно возможить на cms.
Да, это отчасти так — очень многое зависит от разработчика. Но общий срез по рынку это не отменяет.
К первому графику я могу добавить, что группа CMS набравших 3,4% это долбно мощные решения, порог вхождения в которые достаточно велик и абы какой фрилансе делать на них сайты не возьмется, тем более платность CMS тоже сильно урезает круг желаюших её использовать в каждодневной работе, отсюда процент сайтов с кучей сомнительных модулей и самописного кода плохого качества у этих CMS весьма низок отсюда и такие хорошие показатели.
Вобщем-то, вы абсолютно правы. Например, похожий вывод мы явно пишем по второму срезу «Одной из гипотез авторов исследования является то, что сайты на коммерческих CMS чаще разрабатываются силами профессиональных разработчиков, которые своевременно следят за обновлением версий, что приводит к большей доле зараженных проектов на бесплатных решениях.»
Вопрос! «Выборка сайтов с определением типов CMS была предоставлена компанией iTrack». В списке на сайте компании есть MODx и Drupal. Они не участвовали в вашем исследовании, или их доля на рынке столь мала, или нет зараженных сайтов с их использованием?
И еще вопрос про первую диаграмму. Не совсем понятно что на ней изображено. Вот есть множество всех обнаруженных при исследовании зараженных сайтов. На диаграмме — доля каждой CMS в этом множестве? Если да, то лучше назвать «Доля в зараженных сайтах», чтобы не возникало второй трактовки.
Вторая трактовка такая: Есть некоторая CMS foo. Во множестве всех исследованных сайтов количество сайтов с этой CMS count(foo), а количество проблемных сайтов — bad(foo). На диаграмме нарисована доля зараженных сайтов, то есть bad(foo)/count(foo). Но тогда совершенно не понятно, как сумма этих показателей для различных CMS равна примерно 100% и зачем их рисовать на круглой диаграмме.
PS Сорри, слишком долго писала, ответы есть выше. Удалять коммент уже не буду.
И еще вопрос про первую диаграмму. Не совсем понятно что на ней изображено. Вот есть множество всех обнаруженных при исследовании зараженных сайтов. На диаграмме — доля каждой CMS в этом множестве? Если да, то лучше назвать «Доля в зараженных сайтах», чтобы не возникало второй трактовки.
Вторая трактовка такая: Есть некоторая CMS foo. Во множестве всех исследованных сайтов количество сайтов с этой CMS count(foo), а количество проблемных сайтов — bad(foo). На диаграмме нарисована доля зараженных сайтов, то есть bad(foo)/count(foo). Но тогда совершенно не понятно, как сумма этих показателей для различных CMS равна примерно 100% и зачем их рисовать на круглой диаграмме.
PS Сорри, слишком долго писала, ответы есть выше. Удалять коммент уже не буду.
UFO just landed and posted this here
MODx крут, но для некоторых задач тяжеловат. Всё-таки интересно, он был в исследовании или нет?
Terekhov,22 января 2014 в 16:07
В анализе участвовало одинаковое количество сайтов на каждой CMS.
Полагаю, что был, т.к. в списке itrack он есть.
Извините, но «модекс тяжеловат» какой? Революшн — возможно, хотя он больше каркас (framework). А Еволюшн для динамичных визиток очень даже шустр.
Очень печалит отсутствие упоминания в тесте. Очень.
Очень печалит отсутствие упоминания в тесте. Очень.
Имелся ввиду Revolution в сравнении с микрофреймворками, которые обычно использую для создания визиток. Даже Revo больше похож на CMS, чем на фреймворк, потому что можно собрать полноценный сайт без программирования (и даже не представляя, что это такое — программировать). А вот порог вхождения для разработки собственного модуля заметно выше, чем в других фреймворках, на мой взгляд.
Тяжеловат? И это после того как в статье упоминаются Битрикс и Джумла???
Мне кажется что MODx скорее CMF всё же. Там конечно есть админка и всё-такое, но её нельзя поставить, как например wodpress, скачать шаблон и использовать.
UFO just landed and posted this here
Не совсем с вами согласен. Здесь надо разделить modx revo и evo. Первый поддерживает скачивание и установку стандартных шаблонов. Второй идет к этому.
Установка чуть сложнее, чем у остальных, зато полная свобода в использовании и управлении.
Вот вопрос с безопасностью. В MODx вообще сложно накосячить так, чтобы сайт лег и не встал. За счет хранения пользовательских данных в БД и их обработки на входе — очень удобно. При этом сама система мониторит свое состояние и, чуть что, оповещает владельца.
Думаю, что MODx — это пограничное, между CMF и CMS.
Установка чуть сложнее, чем у остальных, зато полная свобода в использовании и управлении.
Вот вопрос с безопасностью. В MODx вообще сложно накосячить так, чтобы сайт лег и не встал. За счет хранения пользовательских данных в БД и их обработки на входе — очень удобно. При этом сама система мониторит свое состояние и, чуть что, оповещает владельца.
Думаю, что MODx — это пограничное, между CMF и CMS.
Чёрт возьми, вы правы! :)
Извините, это был не сарказм. Просто я действительно только что зашёл в управление пакетами и нашёл там шаблоны :) Мы всегда использовали modx только с уникальным дизайном и вёрсткой для каждого заказчика. И поэтому я их как-то не замечал :)
Да, modx это что-то среднее между CMF и CMS. Так же как TYPO3. Когда я последний раз работал с TYPO3 там точно не было готовых шаблоном. Но это было очень давно. Возможно тот, кто использует сейчас TYPO3 меня поправит.
Извините, это был не сарказм. Просто я действительно только что зашёл в управление пакетами и нашёл там шаблоны :) Мы всегда использовали modx только с уникальным дизайном и вёрсткой для каждого заказчика. И поэтому я их как-то не замечал :)
Да, modx это что-то среднее между CMF и CMS. Так же как TYPO3. Когда я последний раз работал с TYPO3 там точно не было готовых шаблоном. Но это было очень давно. Возможно тот, кто использует сейчас TYPO3 меня поправит.
Спасибо!
Мы тоже пользуемся уникальными шаблонами, и я столкнулся с ними так: зашел на сайт modx почитать документацию по какому-то сниппету и увидел шаблоны на Zurb Foundation, подивился, и пошел внутрь. Так я осознал, что MODx по свой философии похож на линукс: у тебя есть ядро, а что ты с ним будешь делать и как — это твои проблемы. Хоть звезду смерти, хоть самокат.
Признаюсь, TYPO3 у нас не взлетел. Также как некоторые другие системы, типа jooml'ы и прочих CMS, которые очень сильно ограничивают вмешательство в работу. В этом смысле мы уже определили свой пакет: MODx, Newscoop, OpenCart, Esotalk и для внутреннего использования у нас и у клиентов Collabtive и SugarCRM.
А что используете вы?
Мы тоже пользуемся уникальными шаблонами, и я столкнулся с ними так: зашел на сайт modx почитать документацию по какому-то сниппету и увидел шаблоны на Zurb Foundation, подивился, и пошел внутрь. Так я осознал, что MODx по свой философии похож на линукс: у тебя есть ядро, а что ты с ним будешь делать и как — это твои проблемы. Хоть звезду смерти, хоть самокат.
Признаюсь, TYPO3 у нас не взлетел. Также как некоторые другие системы, типа jooml'ы и прочих CMS, которые очень сильно ограничивают вмешательство в работу. В этом смысле мы уже определили свой пакет: MODx, Newscoop, OpenCart, Esotalk и для внутреннего использования у нас и у клиентов Collabtive и SugarCRM.
А что используете вы?
Мы по-началу использовали TYPO3, но потом решили что это оверкилл. В данный момент используем только MODx и opencart :) Пока что для всего хватает. В MODx пишем свои сниппеты и плагины, а opencart пытаемся через vqmod дописывать, что не особо удобно :) Последнее время начинаем ощущать что opencart перестаёт хватать. Будем искать что-то ещё :) Буду рад если кто-то тоже поделится своим списком движков для интернет магазинов :) Ну а для внутренней кухни используем redmine, а CRM у нас встроена в программу которую использует бухгалтерия.
А Collabtive вы используете адаптированным или из коробки?
Есть ли там у вас древовидный список задач, комментарии к ним, хотя бы?
Есть ли там у вас древовидный список задач, комментарии к ним, хотя бы?
opencart, там проблем с безопасностью меньше всего
Используем и как ecommerce систему и как CMS (с модулем ocCMS)
Используем и как ecommerce систему и как CMS (с модулем ocCMS)
Вот вопрос с безопасностью.И что вас тут интересует? Стандартные SQL-injection, XSS и т.п.? Да, этого почти нет. Зато уязвимостей рода LFI и выполнение произвольного кода — за глаза. Самое интересно, что именно
За счет хранения пользовательских данных в БДэксплуатация банальных уязвимостей доступна только тем, кто знает MODX. Вот скажите, разве нормальному человеку придет в голову использовать такую строчку для выполнения произвольного кода:
[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]*id:gte=`5`:then=`phpinfo();`:else=`2`:math=`?+1`]]Хотя не спорю, после моих багрепортов это дело поправили. Но кто мешает нам задействовать 2 разных поля одной формы получая в конечном итоге запрос вида (демо на modx.com):
&aField=[[*[[*id:gte=`1`:then=`id`:else=`&bField=id`]]]]А еще можно сделать интеграцию с RSS лентой.
Но и конечно же чтобы обезопасить себя нужно фильтровать все входящие данные. Т.е. писать что-то типа такого:
str_replace(array('[',']','`'),array('[',']','`'), $value);При этом нужно знать еще одну особенность — сохранение пользовательских данных в ТВ параметр при определенных условиях позволяет выполнить произвольный код. Поэтому создавая документы по данным формы с фронта нужно данные фильтровать не только на предмет XSS, но еще и на наличие начальных фраз типа @ EVAL, @ SELECT.
Если вы думаете, что на этом все, то нет. При определенных условиях пользователь может обойти ограничения безопасности. Поэтому нужно знать как расширять профиль пользователя при необходимости (а инструкций нет — разбирайтесь в коде сами) + нужна правильная настройка политик безопасности, а их тут миллионы комбинаций (шаг не в ту сторону — пиши пропало).
Итого, MODX — Неуловимый Джо. Это еще год назад заметил один из членов сообщества MODX (не буду показывать пальцем). Таким образом, вся безопасность MODX основана лишь на отсутствии желания у нормальных ребят разбираться во всем этом бреде, т.к. вместо того, чтобы проверить парочку новых компонентов для той же самой Joomla потребуется время на взрыв стереотипов и разбор этого «удобного» до поры до времени синтаксиса.
Для использования [[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]*id:gte=`5`:then=`phpinfo();`:else=`2`:math=`?+1`]] нужно иметь доступ к управлению контентом. Мне кажется что кто-попало не имеет такой доступ. А защита от инсайдерских атак — это уже дело другое. Поправьте меня.
Вы серьёзно так делали? Можно узнать подробнее причины которые могут подвигнуть на такое? Для хранения пользовательских данных стоит использовать сниппеты, которые будут хранить данные в своих таблицах, но никак не создавать для этого документ.
Поэтому создавая документы по данным формы с фронта
Вы серьёзно так делали? Можно узнать подробнее причины которые могут подвигнуть на такое? Для хранения пользовательских данных стоит использовать сниппеты, которые будут хранить данные в своих таблицах, но никак не создавать для этого документ.
Для использования [[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]*id:gte=`5`:then=`phpinfo();`:else=`2`:math=`?+1`]] нужно иметь доступ к управлению контентом. Мне кажется что кто-попало не имеет такой доступ
ОМГ. Смотрите видео внимательно, а потом учите меня делать сайты
Сайты на Drupal, TYPO3, MODx вообще не попали в список
Значит вывод делается вообще неправильный
Значит вывод делается вообще неправильный
Можно ли где-то посмотреть детальную статистику по CMS, где указаны конкретные проблемы в безопасности? Например сколько вредоносного кода (как проверяли?) обнаружили на сайтах? Какова процентная доля используемых критериев? Скажем, «Версия CMS и веб-сервера» как учитывается в исследовании?
А куда со второй картинки пропали 10%?
Доли веб-серверов и доли найденных уязвимостей для каждого сервера совершенно не совпадают. Сравните w3techs.com/technologies/overview/web_server/all
Выборки разные. Да и nginx с apache часто работают в связке, так что вообще неясно, что и как считать.
Выборки, действительно, разные. К тому же мы исследовали рунет, а статистика по ссылке — глобальная.
Пожалуйста, по рунету — openstat.ru. Примерно тоже самое. У IIS ну никак не 0.41%, а у nginx не 70%
openstat.ru собирает только по сайтам с их кнопкой.
Есть другие источники:
statonline.ru/metrics/web_server_soft?tld=ru
w3techs.com/technologies/breakdown/ws-nginx/top_level_domain
Есть другие источники:
statonline.ru/metrics/web_server_soft?tld=ru
w3techs.com/technologies/breakdown/ws-nginx/top_level_domain
Упс, вторая ссылка должна была быть:
w3techs.com/technologies/segmentation/tld-ru-/web_server
w3techs.com/technologies/segmentation/tld-ru-/web_server
Небольшое замечание (вдруг кому-то это не очевидно) — из статистики и заголовка (конечно, если верим этому исследованию), вроде бы следует вывод, что надо выбирать платную — хоть дороже, зато безопаснее.
Но те же факты могут быть и объяснены другой причиной. Когда Пупкин строит хоумпейдж своей аквариумной рыбке, он делает его, скажем, на вордпрессе. Потом забивает на обновления и слежение за новыми уязвимостями, да и вообще — даже забыл, что у него сайт есть. А сайт тем не менее существует, дырки находятся, его троянят, итд.
Когда в большой компании вроде Аэрофлота делают сайт — то будут две отличных от «пупкиного» примера вещи: во-первых, у аэрофлота 100500 сисадминов, программистов, безопасников, разработанные политики безопасности, куча правил и инструкций итд. во-вторых — есть деньги на CMS, и даже как-то позорно, на бесплатной системе делать сайт. Поэтому сайт Аэрофлота будет гораздо стабильнее и безопаснее сайта про рыбку. А если мы подарим Пупкину лицензию на коммерческую CMS, то все равно, у него не будет нескольких сисадминов-вебмастеров с сертификацией по этой CMS, «и вообще».
При таком раскладе, выбор в пользу платной CMS, ничуть не делает сайт безопаснее.
Но те же факты могут быть и объяснены другой причиной. Когда Пупкин строит хоумпейдж своей аквариумной рыбке, он делает его, скажем, на вордпрессе. Потом забивает на обновления и слежение за новыми уязвимостями, да и вообще — даже забыл, что у него сайт есть. А сайт тем не менее существует, дырки находятся, его троянят, итд.
Когда в большой компании вроде Аэрофлота делают сайт — то будут две отличных от «пупкиного» примера вещи: во-первых, у аэрофлота 100500 сисадминов, программистов, безопасников, разработанные политики безопасности, куча правил и инструкций итд. во-вторых — есть деньги на CMS, и даже как-то позорно, на бесплатной системе делать сайт. Поэтому сайт Аэрофлота будет гораздо стабильнее и безопаснее сайта про рыбку. А если мы подарим Пупкину лицензию на коммерческую CMS, то все равно, у него не будет нескольких сисадминов-вебмастеров с сертификацией по этой CMS, «и вообще».
При таком раскладе, выбор в пользу платной CMS, ничуть не делает сайт безопаснее.
Итак, с точки зрения не то, что хостера, а так человека, который плотно работает с хостингами.
Всё это личная эмпирическая точка зрения.
60-70% всех проблем — вредоносный код в скаченных не_пойми_откуда шаблонах/компонентах.
Еще 10-20% — увод доступов троянами и «непонятными личностями».
Остальное — уязвимости CMS.
Важно: не затрагивается массовая эксплуатация уязвимостьей, которая применима в принципе только в контексте конкретной CMS.
К слову сказать, если у хостера руки из правильного места, различные php-шелы/blackmailer-ы в большинстве случаев блокируются на автомате при первой попытке использования(часто вообще до, если файл с известно сигнатурой приполз по ftp).
Всё это личная эмпирическая точка зрения.
60-70% всех проблем — вредоносный код в скаченных не_пойми_откуда шаблонах/компонентах.
Еще 10-20% — увод доступов троянами и «непонятными личностями».
Остальное — уязвимости CMS.
Важно: не затрагивается массовая эксплуатация уязвимостьей, которая применима в принципе только в контексте конкретной CMS.
К слову сказать, если у хостера руки из правильного места, различные php-шелы/blackmailer-ы в большинстве случаев блокируются на автомате при первой попытке использования(часто вообще до, если файл с известно сигнатурой приполз по ftp).
А как же wordpress? :)
Мы пару раз пытались блог на wordpress поставить и заканчивалось это заражением. Последний раз пришлось его ограничить через open_basedir. И теперь в этом блоге друг с другом общаются спам-боты. А некоторые начали уже даже посты писать.
Это ни в коем случае не попытка начать холивар. Просто мой личный опыт. Возможно я просто не умею его готовить :)
Мы пару раз пытались блог на wordpress поставить и заканчивалось это заражением. Последний раз пришлось его ограничить через open_basedir. И теперь в этом блоге друг с другом общаются спам-боты. А некоторые начали уже даже посты писать.
Это ни в коем случае не попытка начать холивар. Просто мой личный опыт. Возможно я просто не умею его готовить :)
А причем тут спам боты и заражение, они в коментариях общаются или я чего-то не понимаю.
А так берете самый новый стабильный релиз WP ставите его, выставляете правильные права на файлы, делаете нормальный конект с бд, ставите пароль на админа символов 30. Не ставите сторонних обновлений если не уверены в них.
А так берете самый новый стабильный релиз WP ставите его, выставляете правильные права на файлы, делаете нормальный конект с бд, ставите пароль на админа символов 30. Не ставите сторонних обновлений если не уверены в них.
Они сами публикуют (у нас была включена модерация) свои коменты :) А некоторые особо обнаглевшие стали публиковать посты :)
Делали ровно как вы описали. Всегда ставили только самую последнюю версию. И потом в директории блога находили кучу веб шеллов. Ставили по инструкции. Пароль был конечно не 30 символов, но довольно стойкий. Возможно стоило чаще обновлять wordpress :)
Делали ровно как вы описали. Всегда ставили только самую последнюю версию. И потом в директории блога находили кучу веб шеллов. Ставили по инструкции. Пароль был конечно не 30 символов, но довольно стойкий. Возможно стоило чаще обновлять wordpress :)
Да, есть такие хостеры за $1, у которых можно получить список пользователей, прочесать /home//public_html/<стандартные конфиги CMS>. Когда таким хостерам об этом сообщаю, они молча стирают твой аккаунт с сервера, возвращают платёж и всё.
Значит что-то не так ставили, блогов на WP сотни тысяч и я не особо вижу что-бы на них был такой ужас со спам ботами.
А некоторые особо обнаглевшие стали публиковать посты :)
Фантастика :)
Чаще всего ломают через установленные сторонние плагины.
Своевременно обновляйте WP и все будет хорошо.
Datalife Engine занимает такую долю по зараженности благодаря зараженным дистрибутивам, распространяемым на варез-сайтах.
Сделайте, пожалуйста, график «доля CMS у которых нет проблем с безопасностью», чтобы видеть лидеров а не аутсайдеров :)
Порадовал Drupal. Даже у сайтов с версией, не обновляемой почти 3-4 года — нет проблем.
Порадовал Drupal. Даже у сайтов с версией, не обновляемой почти 3-4 года — нет проблем.
блин глаза сломаешь пока поймешь какой оттенок к какой легенде относится. вы про зеленый, розовый, серый и массу других отличающихся от предложенных оттенков слышали?
В instantcms цифра такая большая не из-за проблем системы, а из-за большого количества nulled компонентов, которые ставят себе юзеры.
Sign up to leave a comment.
Исследование безопасности сайтов на различных CMS