Почему взламывают даже защищённые CMS на безопасном хостинге. Взлом битрикс
Почему взламывают даже защищённые CMS на безопасном хостинге
Очевидно, что если у сайта есть уязвимости, то его можно взломать с помощью веб-атак. Но даже если сайт защищен техническими средствами, работает на надежной CMS, его все равно могут скомпрометировать. Каким образом это происходит и как защищать сайт от различных вариантов взлома не через веб-уязвимости — oб этом рассказал на партнёрской конференции «1С-Битрикс» Григорий Земсков, руководитель компании «Ревизиум». С каждым годом растет число взломов и пострадавших от них владельцев сайтов. А в последние два года проблема безопасности сайтов становится особенно актуальной: в разы возросло число атак и объемы входящего опасного трафика, и, как следствие, количество взломанных ресурсов. Видя это, веб-мастера и владельцы веб-проектов постепенно начинают осознавать проблему и интересоваться вопросами информационной безопасности сайтов, в частности, их защитой. Для того, чтобы грамотно защитить свой ресурс, владелец веб-ресурса должен понимать, какие есть варианты взлома, как действует злоумышленник, какие векторы атак наиболее критичны и как их закрыть.
К сожалению, существует очень много статей и видео, которые вводят в заблуждение интересующихся этими вопросами. Проблема здесь в том, что вопрос безопасности освещается однобоко, обычно рассматриваются только технические средства защиты. Причем не в полном объеме, а только те, которые блокируют веб-атаки. Это дает веб-мастерам чувство ложной защищенности и абсолютно не гарантирует бесперебойную работу веб-ресурса и защиту от несанкционированных изменений. В большинстве случаев у владельца сайта нет желания тратить свои ресурсы: деньги, время на безопасность проекта, поэтому выбирается на его взгляд оптимальная стратегия: использовать популярную коммерческую систему управления сайтом и разместить сайт на популярном хостинге. Все, вроде бы, логично: защищенная система работает в защищенной среде, то есть можно более не думать про безопасность и защиту. Но это всего лишь одно из популярных заблуждений про безопасность сайтов, наряду с тем, что достаточно одних лишь технических мер защиты.
Увы, все эти «мифы» — про использование лишь веб-атак для взлома сайтов, про защищенность CMS и достаточность технических мер, приводят к новым массовым взломам сайтов. Что же делать, чтобы этого не происходило? Необходим комплексный подход к вопросу безопасности сайта. Далее мы рассмотрим, почему нужно уделять постоянное и пристальное внимание как техническим средствам защиты, так и организационным мерам. Это важно хотя бы потому, что существует много вариантов взлома сайтов, которые выполняются нетехническими методами и без использования веб-уязвимостей.
Варианты взлома сайтов
Все варианты взлома сайтов можно условно разделить на три большие группы (выделены жёлтым, голубым и серым цветом):Больше всего говорят и пишут про взломы посредством веб-атак. Поскольку данный аспект освещен достаточно хорошо, в этой публикации я лишь вскользь упомяну о нем, а основной акцент хотелось бы сделать на двух незаслуженно забытых категориях: компрометации ресурсов техническими средствами без использования «человеческого фактора» (желтый блок) и взлом по вине подрядчиков и сотрудников, то есть тех, кто помогает обслуживать сайт. В количественном выражении взломы через веб составляют около 75%, чем и обусловлено столь пристальное внимание к этому классу.
Что касается остальных двух, то они не такие популярные, но все же не менее важные. По нашей статистике, на взлом по вине подрядчиков и сотрудников приходится около 5% инцидентов. Но эта цифра постепенно растет, поскольку в настоящий момент много сайтов отдается на обслуживание в веб-студии, диджитал-агентства или фрилансерам.
Итак, рассмотрим варианты по-порядку. Начнем с самой многочисленной группы, взлом сайта посредством веб-атак:
- В большинстве случаев это становится возможным в результате эксплуатации уязвимостей
- в скриптах CMS, в плагинах и модулях. Разработчики допускают ошибки: недостаточно фильтруются входные параметры, не проверяются размещаемые в базе данные, информация выводится на странице «как есть», без безопасных преобразований.
- в доработках. Можно поставить безопасную CMS, но при этом позвать неопытного разработчика. Он допишет плагин, в который внесет иногда не одну критическую уязвимость и через них взломают сайт. Веб-программист должен быть знаком с принципами безопасной разработки, а владельцу сайта следует обращаться к опытным подрядчикам.
- Второй вариант взлома сайта возможен благодаря брутфорсу панелей администрирования, то есть подбору логинов/паролей. Это очень распространённый тип атаки, особенно на защищенные CMS. По-прежнему пользователи устанавливают короткие или словарные пароли, которые с легкостью перебираются злоумышленниками и могут быть подобраны за конечное время. В результате доступ к админ-панели можно получить буквально за несколько минут. Ситуация усугубляется тем, что доступ в панель администратора обычно не ограничивается дополнительными средствами, такими как двухфакторная аутентификация, разрешенным списком IP-адресов, а число неверных попыток входа не ограничено.
Защита от веб-атак
Избавиться от веб-атак нельзя, но им можно противодействовать. Ниже представлен список мер против взлома через веб.- Необходимо обновлять CMS и скрипты. С каждой новой версией выходят патчи безопасности: закрываются уязвимости, исправляются ошибки. Всё это позволяет снизить вероятность взлома через веб, хотя и не защищает от него на 100%, потому что и в новых апдейтах, к сожалению, могут появиться новые «дыры».
- Необходимо минимизировать объем плагинов в CMS. Чем больше плагинов, тем больше вероятность наличия уязвимостей. В идеале, использовать решение «из коробки», с примененными патчами и критическими обновлениями, которые закрывают все известные публичные уязвимости в ядре CMS. Но, поскольку, функциональности не всегда хватает, то перед установкой плагинов нужно обязательно проверять, насколько они защищены и безопасны.
- Доработки нужно отдавать опытным веб-разработчикам, которые имеют представление о безопасности сайтов и источниках проблем, то есть понимают необходимость фильтрации входных и выходных параметров, безопасных алгоритмов аутентификации и авторизации, безопасного хранения данных и т.п.
- Трафик необходимо фильтровать. По статистике сервисов проксирования трафика, около 50% всех запросов идут от ботов, причем примерно четверть тех запросов – это атаки на веб-ресурс. Фильтрация запросов к сайту блокирует атаки, паразитный трафик и снижает нагрузку при DDOS- и брутфорс-атаках. Фильтровать можно как с помощью внешнего сервиса (Web Application Firewall/AntiDDOS), так и модуля веб-сервера (naxsi/mod_security). Еще одна полезная функция WAF – это виртуальный патчинг уязвимостей. Необязательно (да и не всегда возможно) ставить «заплатки» на скрипты, но WAF может выполнять виртуальный патчинг, то есть на лету блокировать опасные запросы, не давая эксплуатировать уязвимость. Кроме сервиса и модуля веб-сервера, файрвол бывает встроен в CMS. Он, конечно, не может быть полноценной заменой внешних сервисов WAF или AntiDDOS, но частично снижает вероятность взлома в результате веб-атак.
- Необходимо использовать плагины и сервисы для защиты от брутфорса. Скажем, установленный на VPS Fail2ban через несколько неудачных попыток авторизации на некоторое время блокирует клиента. Это существенно затрудняет и растягивает во времени подбор пароля.
Если CMS неуязвима
Почему взламывают даже неуязвимые CMS на безопасном хостинге? Причина кроется в том, что существуют и другие варианты компрометации или заражения сайтов, совсем не обязательно, что сайт взломают через уязвимости в скриптах. Приведу несколько из них:- Из нашей практике, самый популярный вариант — это взлом через «соседей» по аккаунту. Например, на виртуальном хостинге размещен сайт, безопасности которого уделяется большое внимание: он работает на обновленной версии CMS, к нему применены технические средства защиты. Но на том же shared-аккаунте может быть размещено еще два десятка сайтов с уязвимыми версиями CMS, или размещаться старая тестовая версия сайта, про которую все давно забыли, а в ней может быть открыт загрузчик файлов или доступна без аутентификации админ-панель. Подобные незащищенные сайты и являются источниками проблем безопасности. Через их уязвимости можно внедрить администратора сайта в базу данных, загрузить веб-шелл или бэкдор, а затем получить полный контроль над аккаунтом хостинга. Почему это возможно? На shared-аккаунтах, где нет физической изоляции сайтов друг от друга, все данные расположены внутри общего файлового пространства (у файлов аккаунта общий пользователь операционной системы), то есть скрипты одного сайта могут читать, изменять, удалять скрипты, шаблоны и базу данных другого сайта на том же аккаунте. Это является причиной массовых взломов сайтов на аккаунте, когда однотипное заражение наблюдается на всех ресурсах виртуальной площадки. Это касается не только виртуальных хостингов, но и VPS-серверов. Часто, даже при технической возможности и абсолютной дешевизне, на выделенном сервере создается один административный аккаунт (пользователь admin), и внутри него размещается несколько десятков сайтов на различных CMS. А для взлома всего аккаунта достаточно иметь одну единственную критическую уязвимость на любом из этих сайтов. За пару секунд на каждый сайт будет загружено несколько десятков вредоносных скриптов, а процесс лечения будет напоминать вычерпывание воды из дырявой лодки: с одного сайта убрали вредоносный код, а он с другого опять «перешел» на вылеченный. Поэтому одно из базовых правил безопасности сайтов – изолированное размещение сайтов.
- Следующий вариант взлома защищённого сайта — брутфорс SFTP/FTP-аккаунтов или SSH-доступов. Для своего удобства и к радости злоумышленников веб-мастера устанавливают слабые словарные пароли, которые попадают в ТОП-100, ТОП-1000 популярных и подбираются за пару часов.
- Третий вариант — взлом через phpMyAdmin (а также другие инструменты, которыми пользуются веб-разработчики и администраторы). PhpMyAdmin — это средство администрирования базы данных. Распространяется по open source-лицензии, удобный, простой, доступный, его ставят на все хостинги и выделенные сервера под управлением популярных панелей. Самое интересное, что адрес у него почти всегда фиксированный. То есть можно набрать имя_сайта/myadmin или /phpmyadmin, и откроется форма авторизации phpmyadmin. Если туда ввести пароль и логин от базы данных, которые можно узнать различными методами, вы получите доступ к базе данных. А дальше с помощью SQL-запроса можно внедрять вредоносный код в шаблоны, читать или создавать файлы на диске. А это уже могут быть бэкдоры, позволяющие загружать произвольные файлы и выполнять произвольный код. Многие хакеры напрямую внедряют код в базу данных, и при этом не оставляют никаких следов в файловой системе. То есть владелец сайта или веб-мастер просто не поймет, каким образом вирус появляется в коде страницы.
У читателя может возникнуть вопрос: каким образом злоумышленник узнает логины и пароли от базы данных, ведь для этого нужно получить доступ к файлу конфигурации CMS? На самом деле, получить данные для подключения к БД намного проще, чем кажется. Иногда запрос в поисковую систему Google позволяет найти очень много проиндексированных файлов, содержащий различную «чувствительную» информацию. Например, бэкапы сайтов с файлом настроек, или ошибочно проиндексированные файлы конфигурации. В качестве примера можно взять один старый запрос из Google Hacking Database – хакерской базы данных, содержащей запросы к Google для поиска проиндексированных уязвимых скриптов и чувствительных файлов.
Вводим его в строку поиска и получаем примерно 288 файлов, которые содержат открытый логин, пароль, хост. Остается просто взять их оттуда, зайти на страницу /myadmin (или аналогичную для конкретного хостинга) и авторизоваться для проведения операций с базой данных.
Второй вариант простого получения пароля от базы данных — это поиск бэкапов. Злоумышленник может получить несанкционированный доступ к резервным копиям сайта, если они лежат в корневом каталоге сайта (часто их называют backup.zip, backup.tar.g и т.п.) или в случае небезопасной настройки веб-сервера, когда каталог backup открыт для чтения по прямой ссылке (а иногда его даже индексирует поисковик). То есть злоумышленники по каким-то фиксированным путям (в Wordpress это wp-content/uploads или /backups) могут перебрать различные имена файлов и выгрузить бэкап сайта. В этом архиве находится конфигурационный файл, в котором хранятся необходимые доступы к базе данных.
- Еще один вариант заражения сайта – когда веб-мастер добровольно устанавливает зараженный компонент. Например, вместо покупки плагина или шаблона для сайта, он скачивает этот же архив с «варезных» сайтов или каталога тем. А в этом плагине уже «вшит» бэкдор или вредоносный код. Естественно, через некоторое время такой сайт взламывают.
- И последний вариант, редко встречающийся у крупных хостеров, но периодически возникающий среди владельцев выделенных серверов – это «рутование» сервера (взлом сервера и получение административных полномочий). Это возможно в том случае, если программное обеспечение, компоненты операционной системы и сервисы содержат уязвимости или ошибки настройки. Если VPS-сервер не администрируется специалистом, то его достаточно быстро взламывают через известные уязвимости, а затем уже, как следствие, взламывают и все находящиеся на нем сайты.
- Перехват или кража доступов, то есть компрометация доступов к сайту.
- Брутфорс-атака на сервисы: SFTP, FTP, SSH или административную панель хостинга.
- Взлом сайтов через «соседей».
- Компрометация сервера хостинга, то есть получение несанкционированного доступа через уязвимости или ошибки настройки.
Защита от взлома
Как от этого защищаться?- Нужно правильно подбирать хостера, обращать внимание на используемые технические средства и сервисы, на наличие изоляции сайтов внутри аккаунтов. Всё это значительно снижает вероятность взлома.
- Размещайте сайты изолированно. Не экономьте на безопасности, не ленитесь создавать для сайтов отдельные аккаунты. В идеале нужно размещать каждый сайт на отдельном аккаунте. Если это сервер, также создавайте для каждого сайта отдельный пользовательский аккаунт. Сейчас даже можно найти хостинг-компанию, у которой сайты размещаются изолированно внутри shared-аккаунта. Таких не много, но они есть.
- Используйте ограничение по IP или двухфакторную аутентификацию при входе в панель управления, при работе с FTP и SSH. Нужно обязательно устанавливать дополнительную защиту, то есть ограничивать доступ только для доверенного круга лиц.
- Регулярно меняйте пароли. Очевидный совет, которому следуют единицы. Это защищает во многих случаях, даже при компрометации доступов. Если злоумышленник не успел ими воспользоваться, то регулярная смена паролей позволяет сохранить свой доступ к сайтам. Дело в том, что вы не знаете, был ли факт компрометации и исходить нужно из пессимистичного сценария. Поэтому в качестве превентивной меры необходимо регулярно устанавливать новые пароли.
Кроме того, важно не просто их менять, а иметь некую разработанную политику безопасности, определяющую процедуру смены паролей с точки зрения частоты и стойкости. Это должен быть спланированный и поддерживаемый процесс.
- При работе с сайтом по FTP/в админке используйте VPN для предотвращения перехвата доступов, чувствительных и конфиденциальных данных.
- Забудьте про FTP и заблокируйте его на хостинге, так как он небезопасен. Если на аккаунте есть такая возможность, подключите SFTP — это надстройка над SSH-протоколом для работы с файлами. В настоящий момент он поддерживается практически на всех хостингах. С точки зрения работы с файлами, разницы с FTP вы не заметите, а с точки зрения безопасности – разница колоссальная.
- Если вы очень часто пользуетесь какими-то функциями в панели управления, то создайте отдельный аккаунт с ограниченной функциональностью и вынесите эти популярные функции в этот аккаунт. Если у вас его и взломают, то получат только ограниченный доступ к управлению сайтами.
Когда виноват подрядчик или сотрудник
Порой «уязвимостью», через которую взламывают и заражают сайт, является сам человек. В частности – сотрудники и подрядчики, обслуживающие сайт: контент-менеджеры, SEO-специалисты, веб-разработчики. Какие проблемы безопасности подстерегают владельца сайта в этом случае?- Недобросовестный подрядчик. Часто бывают ситуации, когда сайты отдаются на обслуживание фрилансерам, которые не всегда добросовестны. Например, есть вероятность, что в результате сотрудничества ему что-то не понравится, покажется мало денег, он обидится на критику и начнет шантажировать владельца сайта доступами. Или он просто использует свои полномочия администратора и повредит сайт. Поскольку у подрядчика есть полный контроль над сайтом, он может внедрить на страницы вредоносный код, может начать продавать на нем ссылки с биржи Sape.ru/Trustlink/и пр., размещать несанкционированную рекламу. И порой владелец сайта или менеджер проекта не догадываются, что бывший веб-мастер «паразитирует» на веб-ресурсе, оставив на нем свои «закладки».
- Бывает, что подрядчик устанавливает плагины, которые содержат уязвимости или бэкдоры. Например, владелец сайта находит красивый плагин галереи для сайта и просит фрилансера купить и настроить этот модуль. Фрилансер находит такой же плагин на «варезном» сайте, берет деньги с заказчика на покупку, но на самом деле скачивает бесплатно. В «нулленом» варианте будет присутствовать некая «полезная» нагрузка в виде бэкдора или «черных» seo-ссылок. Владелец сайта об этом скорее всего никогда не узнает, потому что не будет проверять то, что установил фрилансер.
- Утечка доступов — тоже очень серьезный момент, потому что часто подрядчики не задумываются о безопасности клиентских доступов и сайтов, и небрежно ими распоряжаются. Например, крупное диджитал-агентство обычно работает по различным задачам с партнерами (субподрядчиками), которым передаются клиентские доступы, и что с ними делают партнеры, никто не знает. Эти доступы могут передаваться открыто через мессенджеры по небезопасному сетевому подключению, сохраняться в текстовых файлах, храниться в различных незащищенных CRM и т.п. В итоге шансов раскрытия данных доступов масса, и достаточно сложно будет найти причину компрометации.
Самый живой пример — это когда такой партнер крупного диджитал-агентства сидит в кафе, обновляет сайт по FTP, а где-нибудь рядом с ним устроился хакер, который перехватывает трафик в той же WIFI сети. Или роутер, через который работает специалист в коворкинг-кафе, заражен трояном. Вредоносное ПО собирает все эти доступы и передает злоумышленникам. Сейчас подобное уже не редкость, перехват траффика в открытых сетях – операция очень простая и эффективная. Поэтому работать в публичном месте без активного VPN – это почти преступление.
- И последний вариант — использование социальной инженерии. Скажем, подрядчику, приходит фишинговое письмо: «Ваш сайт взломали! Пожалуйста, срочно смените пароль!» и ссылка. Напуганный исполнитель в замешательстве кликает по ссылке, ему открывается знакомая форма авторизации CMS, но он не замечает, что страница загружена с подставного сайта злоумышленника. Вводит пароль и последний благополучно отсылается хакеру.
- Управлять доступами. Владелец должен знать, когда и как их менять, у кого они есть, кому их передавать и в каком объеме. Это защитит от многих проблем.
- Проводить аудит безопасности после выполнения работ подрядчиком. Файлы, базу и страницы сайта можно проверить самостоятельно с помощью доступных сканеров или инструментов для контроля целостности, а можно обратиться к соответствующим специалистам по безопасности.
- Инструктировать подрядчиков. Обязательно нужно составить руководство по безопасной работе с сайтом для сотрудников и подрядчиков и проинструктировать по нему. Многие специалисты могут отлично выполнять свои задачи, но не задумываться о безопасности сайта.
- Работать по договору и с проверенными компаниями. Сотрудничество с фрилансерами часто оборачивается проблемами безопасности с сайтом.
В заключение
Безопасность – это непрерывный процесс, которому требуется пристальное внимание. Только в случае комплексного подхода к безопасности, включающего в себя обязательное использование технических средств и организационных мер, ваш сайт будет надежно защищен.habr.com
Безопасность сайта в 1С-Битрикс. Инструменты против взлома
Знаю по опыту работы с клиентами, что вопрос безопасности далеко не последний, который их интересует. Правда, клиенты обычно не разбирается в деталях и просто боятся хакеров, взлома сайта или что сайт сломается. Но в целом в своих опасениях правы.
Если вы выбираете CMS для сайта или интернет-магазина и безопасность — это один из критериев, то мой пост позволит вам разобраться, дает ли Битрикс достаточно уверенности.
Сначала выводы
Статья получилось большой, да и тематика скучновата. Поэтому я выводы решил написать в самом начале, чтобы увеличить шансы, что вы их прочтете. Так вот, глядя на объем этого поста, может показаться, что во всем разнообразии инструментов безопасности Битрикса легко запутаться. Но это не так. Все они достаточно простые.
Для рядового пользователя, который не слишком разбирается в технических деталях разработки сайтов, достаточно знать, где смотреть отчет по текущей безопасности сайта, уметь запускать сканер безопасности и монитор качества (и то и другое делается в один клик). Есть места, где можно посмотреть единые сводки — просто и понятно. Таким образом, не надо быть спецом по безопасности, чтобы мониторить безопасность в Битриксе так же как не нужно быть экспертом по веб-аналитике, чтобы смотреть посещаемость своего сайта в Лайвинтернете или Яндекс.Метрике.
Безопасность веб-сайта, это штука которую нельзя игнорировать. Или можно, до тех пор, пока первый раз не прилетит проблем. Битрикс в плане безопасности прокачан очень круто. А самое главное, он дает владельцу сайта понятные инструменты, чтобы безопасность оценивать (а также множество других важных мелочей). Обо всем этом будет в статье.
Поехали.
Проактивная защита против взлома сайта
В битриксе есть целый ряд технических инструментов и организационных мер в безопасности, которые объединены под названием «Проактивная защита».
Все инструменты, перечисленные в этом разделе, доступны начиная с редакции 1С-Битрикс «Стандарт» и выше (в редакции «Старт» их нет). Для некоторых требуется модуль «Веб-аналитика», об этом говорится отдельно.
Проактивный фильтр (Web Application Firewall)
Защищает сайт от взлома посредством большинства известных атак. Фильтр выявляет потенциальные угрозы и блокирует вторжения на сайт, анализирует все данные, которые поступают от посетителя, и отфильтровывает те, что считает подозрительными. Фильтр защищает сайт от взлома, в том числе из-за ошибок в безопасности, допущенных разработчиками. Проактивный фильтр фиксирует попытки атак в специальном журнале, а также информирует администратора сайта о случаях вторжения. Фильтр позволяет блокировать атакующего, добавляя его IP-адрес в стоп-лист.
Нужно отметить, что иногда некоторые действия посетителей сайта, могут выглядеть подозрительно, хотя угрозы не представляют, тогда у фильтра будет ложное срабатывание. Но это дань бдительности. Как слишком чувствительная сигнализация на машине соседа у вас под окнами :-).
Сканер безопасности веб-сайта
Это сервис, который позволяет проверить сайт на безопасность, выявить возможные уязвимости в программной части и определить неверные настройки безопасности CMS, PHP, сервера.
Обычному владельцу интернет-магазина сканер безопасности дает дополнительную причину спать спокойнее. Можно самостоятельно провести тестирование безопасности, посмотреть, что не так и понять как защитить веб-сайт, обратиться к разработчику за консультацией и / или устранением .
Пожалуйста, если что-то обнаружится, не надо сразу спускать на программистов всех собак. Сканер зачастую излишне привередлив.
Отличный инструмент, чтобы проверить, все ли порядке с безопасностью на вашем проекте. Аналогичная проверка, простейший аудит безопасности сайта и отчет с рекомендациями от специалистов в этой области будут стоить от 10-15 т.р. и выше.
Запуск сканирования осуществляется одной кнопкой. После окончания проверки, выводятся результаты со списком всех угроз безопасности, найденных на сайте:
- Сканер покажет недочеты во внутренней организации сайта, например, хранятся ли сессии безопасно.
- Покажет, какие возможности системы для обеспечения безопасности сайта не используются (не включены), какие настройки не выполнены.
- Модуль также выведет все неопасные, но потенциально слабые места в безопасности (простой пароль на базу данных, пониженный уровень безопасности для администраторов) и т.п. мелочи, которые, тем не менее часто оказываются полезными. Например, когда разработчик забыл по окончании работы что-то подправить «как нужно».
Результаты сканирования. Список обнаруженных угроз.
Еще сканер умеет искать потенциальные уязвимости в PHP-коде проекта. Кому интересно как это реализовано, можно подробнее прочитать в блоге Битрикса.
Проверка на безопасность кода PHP на сайте.
Для большинства пользователей, которым технические детали не слишком важны, скажу главное — это инструмент для разработчика, который, вполне может что-то забыть предусмотреть в плане безопасности веб-проекта или просто не знать. Этот инструмент позволяет выявлять возможные проблемы, показывает их чтобы можно было устранить. А вот чтобы разработчик не забыл им воспользоваться, да и не упустил из вида массу других мелочей, относящихся не только к безопасности, в 1С-Битрикс присутствует «Монитор качества», о нем тоже будет сказано в этой статье.
Кроме результатов проверки сайта на уязвимости, даются конкретные рекомендации по устранению. Особенно важные моменты в отчете выделяются красным цветом и обозначены специальным значком.
Веб-антивирус. Защищает сайт от вирусов.
Самый простой способ защитить сайт от вируса — использовать антивирус на своем компьютере. Заражение сайта вирусом обычно происходит от компьютера администратора, который имеет к нему доступ, а не потому, что сайт много времени сидит в интернете :-). Поэтому основная задача веб-антивируса — уведомить администратора сайта о заражении. Вирус на сайте означает что вирус возможно есть и на компьютере администратора, и нужно принять меры.
Веб-антивирус работает на сайте, а не на компьютере администратора, поэтому обычный антивирус обязательно нужен.
В зависимости от настроек, которые будут в нем выставлены, Веб-антивирус, может либо только информировать администратора сайта о подозрении на наличие вируса, либо автоматически выявлять в HTML коде сайта опасные участки и «выпиливать» подозрительные iframe и javascript. Есть возможность добавлять исключения, чтобы антивирус перестал срабатывать на безопасные, но подозрительные (по его мнению) части кода.
Проще говоря, веб-антивирус делает большое доброе дело — блокирует распространение вируса вашим интернет-магазином.
Что это значит на практике? Это значит что ваши посетители не получат от своего антивируса или браузера предупреждение что вашему сайту нельзя доверять. И это хорошо!
Сколько раз вы сами сталкивались с тревожным сообщением «Этот сайт угрожает безопасности вашего компьютера» или «У этого сайта проблемы с безопасностью». Кроме того, поисковые системы не исключат ваш сайт из выдачи за распространение вирусов. А именно так бывает, если сайт долгое время заражен.
Стоп-лист. Забанить мерзавцев!
Иногда хочется заблокировать (забанить) некоторых пользователей или ботов, чтобы запретить доступ к сайту. Это бывает полезно, если пользователи делают тестовые заказы с непонятной целью, систематически пишут неадекватные комменты, спамят рекламой или создают излишнюю активность. Для таких случаев в 1С-Битрикс предусмотрен «Стоп-лист».
Нежелательных пользователей можно добавлять в стоп-лист вручную или автоматически по некоторым событиям.
У стоп-листа есть несколько полезных возможностей:
- Чтобы не забыть разбанить пользователя, а это бывает полезным, поскольку у многих IP-адреса динамические и надолго за одним и тем же юзером не закрепляются, можно выставлять время, в течение которого будет действовать блокировка, после чего снимется автоматически.
- Можно выводить заблокированным посетителям произвольное сообщение, например «Ваш IP-адрес был заблокирован, в связи с повышенной активностью». Или что на мой взгляд интереснее, перенаправлять на сторонние сайты. К конкурентам, например. Пусть ведут свою деструктивную деятельность у них.
- Доступ посетителям и ботам можно ограничивать не только по IP-адресу, но и по маске сети и UserAgent`у (при наличии модуля «Веб-аналитика»), что особенно полезно для блокирования нежелательных ботов.
Используя стоп-лист нужно быть осторожным, чтобы случайно не забанить половину интернета, всех пользователей какого-либо браузера или робота-паука от любимой поисковой системы.
Функционал стоп-листа связан с другими инструментами безопасности (например, с «Проактивным фильтром» или «Контролем активности») это дает возможность блокировать нарушителей (в том числе автоматически), которых выявили другие инструменты.
Контроль подозрительной активности на сайте. Кто здесь?
Много хорошо — плохо. Поэтому излишнюю активность на сайте, особенно исходящую от ботов, нужно блокировать. Конечно, вреда особого от нее нет, но и пользы тоже. Например, если ваш сайт размещен на обычном виртуальном хостинге, который легко справляется с 500-700 посетителей в сутки, то попытка выкачать целиком весь ваш сайт, в 10 потоков, используя TeleportPro, вполне может затруднить его работу для других пользователей или привести к сбою. Не говоря уже о том, кому и с какой целью понадобилось выкачивать ваш сайт.
Вот в таких случаях и приходит на помощь контроль активности. Он позволяет блокировать излишне активных юзеров, ботов, защищает от не особо массивных DDoS-атак, плюс, что очень важно, запрещает попытки подбора пароля к сайту. А чтобы все было аккуратно, и администратор сайта при желании мог контролировать процесс, все действия автоматически пишутся в журнал, где администратор их может время от времени просматривать.
В настройках можно выставить ряд параметров: Какую активность считать «излишней», после которой принимать меры, на какое время блокировать источник активности, какое сообщение ему выводить или куда редиректить.
Настройка автоматической блокировки при повышенной активности на сайте
Как видите, штука вполне полезная и найдет применение в работе сайта. Но к сожалению этот инструмент доступен только в редакциях, с модулем «Веб-аналитика» («Эксперт» и «Бизнес»).
Защита административной части
Сердце сайт — административная часть. Это командный центр, откуда ведется управление Скайнетом проектом. Получив доступ к админке, злоумышленник (или просто криворукий сотрудник-экспериментатор) может натворить много бед, которые долго придется разгребать. Чем сложнее пароль, тем сильне хочется сохранить его на рабочем столе в файле «Пароль от сайта.txt», или в браузере, откуда его тоже обычно не составляет труда достать.
Защита административной части по IP-адресу — еще одна линия обороны. Для этого и предназначен этот инструмент. Его использование делает бессмысленными XSS атаки на компьютер администратора / редактора сайта / контент-менеджера. Кража пароля тоже ничего не даст.
Настройка запрета доступа к административной части.
Защита административной части позволяет открыть доступ для управления сайтом только с определенных IP-адресов или диапазонов.
Для удобства настройки, система показывает текущий IP-адрес пользователя. Кроме того, проверяет, не заблокировал ли пользователь доступ самому себе. Но если так получилось, что вы все же оказались заблокированными, например, у вас поменялся IP-адрес и вы не можете войти в админку, вы можете снять ограничение по IP-адресам, создав (по FTP или через панель управления хостингом) специальный файл (с любым содержимым, можно пустой), но по определенному пути и с нужным названием. Путь до файла и его имя задается в настройках модуля «Проактивная защита». Позаботьтесь заранее о том, чтобы в случае блокировки знать какой файл и где нужно создать.
Путь и имя файла, который нужно записать, на случай если заблокировали сами себя.
Контроль целостности файлов
В 1С-Битрикс, присутствует возможность отслеживать наличие изменений в файлах, как ядра системы, так и публичной части сайта.
Такая функциональность может быть использована, например, для контроля работы стороннего программиста, чтобы понимать в какие файлы вносились изменения, какие новые файлы добавились и не модифицировалось ли ядро.
Для большей безопасности, предусмотрена возможность проверки на целостность самого скрипта, который осуществляет контроль.
Защита сессий
Если злоумышленник получает доступ к авторизованной сессии администратора, то сможет получить доступ и к сайту. Чтобы обезопасить сайт от подобного рода взломов, в 1С-Битрикс предусмотрена защита сессий, использование которой делает кражу сессии бессмысленной.
Помимо функционала защиты сессий, имеющегося в настройках групп пользователей, инструмент «Защита сессий» позволяет хранить сессии пользователей в базе данных, что исключает доступ к ним в случае неверных настроек безопасности на виртуальном хостинге. Кроме того, можно задать время жизни идентификатора сессии, чтобы он изменялся через заданные промежутки времени. Тогда даже украденная сессия перестанет быть актуальной через этот промежуток времени. По умолчанию выставлена 1 минута.
Включение хранения сессий пользователей в базе данных.
Защита от показа сайта во фреймах
Простейший пример — если вы посмотрите на источники переходов на ваш сайт, то увидите, что некоторые ссылки это ваш собственный сайт только с другим адресом. Это и есть открытие во фрейме. Есть сервисы типа snip.ly, которые позволяют ставить ссылки через них, и показывать на стороннем сайте рекламу. Например, если кликнуть по этой ссылке, то вы перейдете в бложик Тёмы Лебедева, где внизу будет моя реклама. При желании к этой рекламе можно будет прикрутить аватарку Тёмы, тогда эффективность будет еще выше.
Чтобы подобные штуки нельзя было провернуть на вашем сайте, в Битриксе есть защита от фреймов.
А вот что об этом пишут сами парни из Битрикса:
Запрет отображения страниц сайта во фреймах других доменов позволяет защитить проект от Clickjacking'a (подсовывание невидимого фрейма с целевого ресурса для получения клика от посетителя), Framesniffing'а и значительно уменьшает вероятность Cross-site scripting атак.
Защита редиректов от фишинга
Фишинг — разновидность интернет-мошенничества.
В Битриксе, как и в любой CMS или сервисе, где необходимо считать клики, есть возможность ставить ссылки через редиректы. Например, в модуле «Реклама». Чтобы злоумышленники не использовали их в своих коварных целях, необходимо включить защиту редиректов.
При включенной защите все ссылки с сайта через редиректы защищаются дополнительным параметром индивидуальным для сайта и для этого перехода. Другие внешние переходы не будут работать.
Перенаправлением на другой сайт, заведомо безопасный (можно задать в настройках). Там же в настройках, можно задать текст с предупреждением пользователя о возможной попытке фишинга.
Хосты/домены
Режим предотвращает подмену HTTP-заголовка Host. Проще говоря, не дает открывать ваш сайт по любым адресам, отличающимся от разрешенных вами. Можно настроить либо блокирование таких попыток открытия сайта, либо переадресовывать посетителя на нужный вам, разрешенный адрес.
Настройка переадресации на разрешенный домен.
Панель безопасности
Инструментов безопасности в Битриксе много, чтобы упростить настройку и определить текущее состояние каждого, предусмотрена Панель безопасности. Это раздел, в котором на одной странице сведена воедино и структурирована вся информация о текущей безопасности сайта в настоящий момент. Здесь же, если необходимо, даются рекомендации по улучшению безопасности. Сразу приведена ссылка на соответствующий инструмент, который нужно включить или настроить.
Панель безопасности 1С-Битрикс.
Чтобы определить уровень безопасности созданного сайта, достаточно зайти в панель безопасности.
Безопасная авторизация без SSL
Если вам приходится работать с сайтом из разных мест, в том числе через открытые точки Wi-Fi, вы подвергаете безопасности сайт, рискуя, что ваши логин и пароль, через которые вы входите на сайт, будут получены злоумышленниками. Перехват паролей не представляет большой проблемы, если сайт не поддерживает шифрование или вы не используете VPN-соединение.
В Битриксе, есть возможность обезопасить авторизацию без необходимости подключать SSL. Для этого в административной панели, в настройках Главного модуля, нужно включить эту возможность, поставив соответствующую галочку. После этого пароли станут шифроваться по алгоритму RSA с ключом 1024 бит и в таком виде передаются на сервер. Взломать их будет невозможно.
Журнал вторжений
В 1С-Битрикс, все необычные или злонамеренные действия автоматически заносятся в Журнал вторжений. Это дает администратору сайта возможность выявлять попытки атак как сразу, в момент проведения (например, получив соответствующее уведомление на емейл) и блокировать IP-адрес злоумышленникам, так и просматривая события в журнале позже. В журнале в зависимости от основных типов атак делаются соответствующие записи: внедрение SQL, атаки через XSS, попытка внедрения PHP. Журнал вторжений отличный инструмент для администратора сайта, позволяющий проводить профилактику и предупреждать попытки взлома анализируя записи.
Журнал вторжений.
Двухэтапная авторизация и одноразовые пароли
Для входа на сайт традиционно используются логин и пароль. Но минус их в том, что стащить их особой сложности не составляет. Есть клавиатурные шпионы, вирусы, которые могут «подсмотреть» пароль и передать злодеям. Пароль может быть украден из запомненных в браузере, подслушан в незащищенных wi-fi сетях.
Поэтому во всех критически важных местах, таких как вход в интерне-банк, при переводе денег в платежных системах, используются одноразовые пароли.
Битрикс тоже так умеет. Одноразовые пароли могут генерироваться специальным устройством, брелоком размером с флешку или приложением, установленным на смартфор с Андроидом на борту.
«Брелоки» для генерации одноразовых паролей.
Таким образом, авторизация на сайте будет проходить в два этапа. Первый, когда вводится логин и пароль. Второй, когда вводится одноразовый пароль, сгенерированный брелоком или специальным приложением в смартфоне.
При таком подходе к авторизации, даже если логин и пароль будут известны злодею, он не сможет ими воспользоваться, поскольку одноразового пароля для второго этапа авторизации у него не будет.
Защита сайта от DDoS
Проактивный фильтр в какой-то мере защищает сайт от DoS-атак, позволяя автоматически заносить в стоп-лист пользователей и ботов, проявляющих на сайте излишнюю активность и тем самым снижать нагрузку, которую они генерируют на сервер. Но против серьезных DDos этого недостаточно.
Совсем недавно, в 15-й версии в Битриксе появилась новая возможность, быстро подключить защиту от DDoS-атак, предоставляемую сервисом Qrator. Сделать это можно как из админки, так и со специальной страницы на сайте Битрикса (если админка Битрикса у вас на сайте будет недоступна из-за DDos-атаки). В лицензию входит бесплатно 1 защита сайта от ddos в год сроком на 10 дней. Больше уже за деньги. Подобный сервис будет интересен, прежде всего крупным проектам. Но говоря про инструменты безопасности, встроенные в Битрикс, не сказать о нем нельзя.
Важные мелочи
Есть еще мелочи, которые относятся к безопасности, но не такие крутые, как те что я описывал выше. Но поскольку совсем не сказать о них в этой статье нельзя, перечислю их, не вдаваясь в подробности. Всё перечисленное в этом разделе доступно в Битриксе начиная с младшей редакции «Старт».
Политики безопасности сайта для групп пользователей
Для разных групп пользователей в Битриксе задаются соответствующие права, разграничивающие доступ к модулям и контенту на сайте. Чтобы пользователи, из разных групп имели доступ только к той информации и логическим операциям, которые им нужны для работы.
Кроме того, для каждой группы пользователей можно настроить свою политику безопасности: Привязать сессию к IP-адресу или сети по маске, определить срок активности сессии и время пока авторизация будет оставаться активной, определить, сколько одновременных авторизаций может быть выполнено для одного пользователя, задать длину пароля и его сложность.
Таким образом, для группы пользователей, которые не имеют на сайте никаких прав кроме просмотра контента в публичной части, можно задать низкий уровень безопасности, а для группы Администраторов установить высокий или даже включить двухэтапную авторизацию, о которой говорилось выше.
Журнал событий
Помимо Журнала вторжений, о котором я уже писал выше, в Битриксе есть еще один — Журнал событий. Здесь логируются события, связанные с авторизацией и регистрацией пользователей, работой разных юзеров с правами доступа, редактирование ими файлов и меню, работа с контентом в информационных блоках (новости, товары, фото и т. п.), что позволяет вести мониторинг основных действий в системе.
Не все возможности журналирования включены по умолчанию, нужно включить их для главного модуля (установив соответствующие галочки) и сделать то же самое в настройках каждого инфоблока.
Настройка в Главном модуле параметров журнала событий.
Настройки параметров для журнала событий в инфоблоке.
На первый взгляд скучная и малополезная штука. Но иногда помогает разобраться кто прав, а кто крайний. Например, когда между контент-менеджерами возникнет спор, кто редактировал последним ту или иную статью на сайте или товар в каталоге и жестко накосячил. Тогда бывает очень полезным заглянуть в журнал событий. Еще журнал событий помогает выявлять попытки автоматического подбора логина и пароля на сайте. Неудачные попытки в журнале видны, если их много, можно принимать профилактические меры.
Монитор качества
Нельзя отрицать, что безопасность сайта, равно как и другие его характеристики (например, быстродействие), зависят во многом от качества разработки. Чтобы помочь владельцу сайта оценить, насколько хорошо сделан его проект, все ли важные нюансы были учтены и/или включены и настроены разработчиком, в битриксе реализован этот инструмент.
Результаты автоматического тестирования сайта монитором качества.
Это набор автоматических тестов для проверки качества разработки вашего сайта, интеграции дизайна, анализа безопасности, производительности, настроек хостинга и много чего еще. Монитор качества не просто показывает на недоработки, а дает рекомендации по устранению.
Не стоит сразу звонить разработчику и ругаться если вы прогоните тест, а он покажет много обязательных пунктов которые не выполнены на вашем сайте. Часто на устранение той или иной «недоработки» требуется всего пара минут.
Детальная настройка CAPTCHA
Капча (CAPTCHA) – старый добрый инструмент защиты от действий ботов. У стандартной капчи есть большой минус, они легко решаются в полуавтоматическом режиме. В 1С-Битрикс есть возможность гибко настраивать капчу. Задавать массу параметров в ее отображении, изменять шрифт, определять какие символы будут выводиться в капче, а какие нет. Такая настройка очень удобная. Например, отличный вариант — капча с кириллицей. А чтобы пользователи не путались, какую буквe им нужно написать, английскую или русскую, можно оставить только цифры и буквы алфавита, которых нет в латинице. Часто этого бывает достаточно, чтобы обмануть и ботов и индусов, которые промышляют решением капч.
Настройка параметров отображения капчи.
Защита от автоматических регистраций
Чтобы боты не регистрировались на сайте автоматически, в настройках главного модуля есть возможность включить подтверждения регистрации по емейл, а чтобы с одного емейла не регистрировались дважды, включить проверку на уникальность. Там же, в настройках главного модуля, можно включить Капчу для регистрации новых пользователей.
Защита от подбора пароля
В Битриксе защита от автоматического подбора пароля реализована двумя способами. Первый — вывод капчи после определенного количества неудачных попыток авторизации. Второй — блокировка пользователя, создающего на сайте повышенную активность. То есть если робот, подбирающий логин и пароль, будет делать это слишком быстро, то проактивный фильтр его просто заблокирует, уведомит об этом администратора сайта и занесет действие в журнал вторжений.
Работоспособность сайта
Безопасность сайта это не только защита от хакеров. Это еще и возможность в случае аварии быстро восстановить сайт. Поэтому в данной статье будут рассмотрены, в том числе и эти инструменты.
Все перечисленные в этом разделе возможности, доступны в Битриксе начиная с младшей редакции «Старт».
Резервное копирование
Сайт — это софт — программное обеспечение и информация. Сам по себе софт сломаться не может. Но может сломаться железо на котором все ваше добро работает. Хостеры серьезно подходят к такого рода безопасности, но шансы потерять все что нажито непосильным трудом тем не менее имеются. Можно найти в интернете немало случаев, когда после аварии у хостера клиент терял свой сайт. Резервных копий у хостера почему-то не оказывалось, владелец их тоже не имел. Остается один вариант – заказывать сайт / интернет-магазин заново. Ждать пару месяцев пока все будет готово, наполнять материалами, продвигать.
Чтобы такого не случалось, продуманные пользователи делают резервные копии и держат их в другом месте, не в той же корзине где лежат все яйца. Не каждый это умеет делать, поэтому в Битриксе возможность резервного копирования реализована очень просто и в разных вариантах. Фактически в пару кликов мышкой. Что именно есть:
Свернуть весь сайт в архив
В этом случае весь сайт (или на выбор, контент /ядро / база данных) будет свернут в аккуратный архив и размещен в специальной папке на сайте. Есть настройка, по которой можно отключить резервное копирование какой-то одной папки или файлов определенного типа. Например, если на сайте хранится видео, можно исключить эту папку из бакапа, чтобы он не был слишком большим. Или если вы знаете, что ядро сайта у вас не менялось, но работа с данными идет каждый день, можно бакапить только публичную часть и БД.
Если сайт большой, то архив будет автоматически порезан на части, размер каждой части можно задавать вручную или оставить по умолчанию. При желании архив можно защитить паролем.
Настройки сжатия хорошо продуманы и подходят для любых хостеров. Можно выставит время работы скрипта и паузы в работе, чтобы процесс не отваливался по таймауту. Можно отключить сжатие, чтобы еще сильнее снизить нагрузку на процессор. Тогда архив будет большим, но сделан будет быстро. Есть галочка, по которой, по завершении архивации, архив будет проверен на ошибки.
Автоматическое регулярное резервное копирование
Чтобы сократить ручную работу и человеческий фактор («забыл сделать очередной бакап»), в Битриксе можно настроить автоматическое резервное копирование по расписанию.
Это здорово упрощает жизнь и позволяет иметь актуальные резервные копии. Чтобы бакапы со временем не заняли все место на сервере, можно настроить автоматическое удаление старых копий.
Автоматический backup в «облако»
Но у хранения резервных копий, там же где лежит сайт, есть минус — в случае серьезной проблемы на сервере, резервная копия тоже будет потеряна. Поэтому хранить резервную копию нужно отдельно от сайта. Это значит, что время от времени нужно копировать резервные копи на другой сервер / хостинг / в облако или к себе в компьютер.
Правило надежного бекапа: «Хранить бекап нужно не на том сервере, где лежит то, что бекапишь».
Чтобы снять с пользователя эту рутину, в Битриксе есть возможность делать резервные копии сразу в облако. Всё то же самое, что описано выше, но после завершения архивации, копия автоматически заливается в облачное хранилище Битрикса или внешнее подключенное к сайту облачное хранилище, например Amazon S3. Плюс для рядового пользователя в том, что облачное хранилище встроено в Битрикс и ничего подключать и настраивать не нужно.
В своем облаке 1С-Битрикс выделяет бесплатно для каждой лицензии определенный объем места под хранение резервных копий:
- 1 Гб. Для редакции Старт,
- 2 Гб. Для «Стандарт»,
- 6 Гб. Для редакции «Эксперт»,
- 4 Гб. Для «Малого бизнеса»
- 10 для Бизнес-редакции.
Не слишком много, но этого достаточно чтобы держать в безопасности 1-2 последних резервных копии. При желании бесплатное место в облаке битрикса можно расширить просто докупив его. Или подключить стороннее облако.
Поддержка облачных хранилищ
Напрямую к безопасности это отношения не имеет, но раз уж начал говорить про облачные хранилища, нужно сказать, что облака подключаются без проблем и работают не только для резервного копирования. За это отвечает специальный модуль, доступный во всех редакциях, начиная со «Старт». После подключения облака к Битриксу, можно настроить в нем хранение файлов любых типов. Например, чтобы все видео, загружаемое на сайт, автоматически размещалось в облаке и для пользователя отдавались именно оттуда. Для некоторых задач это полезно, позволяет разгрузить хостинг и ускорить загрузку инфы посетителями.
Инспектор сайтов
Облачный сервис от 1С-Битрикс, который позволяет мониторить несколько простых, но важных параметров на сайтах и интернет-магазинах, которые работают под управлением битрикса:
- Мониторит работу сайта. Открывается сайт или нет, сколько времени простаивал. Яндекс.Метрика это тоже делает, но этот сервис показывает инфу более детально.
- Проверяет когда закончится домен и уведомляет по почте. Регистратор тоже уведомляет, но бывают случаи когда лицо ответственное за сайт и тот на кого зарегистрирован домен — разные люди. Тогда ответственный за сайт, может не получить емейла от регистратора домена. Чтобы такого не произошло, его уведомит инспектор сайтов.
- Срок истечения лицензии 1С-Битрикс. Казалось бы, не слишком важно. На самом деле экономит деньги. Ведь приобретение льготного продления составляет 20% от стоимости лицензии. Главное, успеть его приобрести в течение 30 дней после окончания лицензии. Не успели, в следующий раз придется оплачивать уже 60% от стоимости. Поэтому важно не пропустить нужную дату.
- Проверять отвечает ли сайта по протоколу https.
- Срок действия SSL сертификата. Проверит и напомнит, когда придет время продлевать SSL-сертификат.
Проставляем галочки что хотим инспектировать.
Так выглядят результаты инспектирования.
Заключение
Сложно спорить, что безопасность сайта, штука важная. Особенно если это интернет-магазин или сайт компании, от работы которого зависит репутация и заработок. Битрикс дает отличные инструменты для работы с безопасностью. Не берусь утверждать, но думаю что в плане защищенности это одна из лучших коробочных CMS в мире.
Все выводы по этой статье я вынес в начало. Повторять их здесь нет смысла. Надеюсь, эта статья помогла вам. Если да, сделайте репост, мне будет приятно :-)
Вконтакте
Google+
webdela.ru
Битрикс и Банки, страшная уязвимость и взлом сайта МК.
В ночь на четверг хакеры атаковали сайт газеты "Московский комсомолец" и полностью уничтожили его содержимое. Вчера работу портала удалось частично восстановить. Сейчас сайт загружается с надписью: "В данный момент по техническим причинам сайт mk.ru недоступен".
Страшная уязвимость Битрикса!!!!! Ужасы, доступ с любых ip!!! Оказывается кто угодно может зайти на страницу авторизации в админку Битрикса!!!! гыА между тем:Сайт МК был на CMS «Битрикс». Сами битриксойды говорят – ничо не знаем, у нас самая защищенная cms и бла-бла, это все неквалифицированные разработчики. Но не все так просто. Сейчас то может они и внедрили свою «проактивную защиту», что есть комплекс мер, одной из которых является блокирования доступа по ip. Но если вы отказались от их платного обновления ядра cms, то рискуете попасть в один из таких списков на хабре.
Уважаемый аффтар primalscream с хабра, Ваш пост скорее реклама, если же нет, то Ваш пост следовало бы отдать в юридические управления перечисленных банков. Спасибо доброму афтару primalscream, который по совместительству еще и главный специалист, отдел интернет-проектов ЗАО ВТБ 24, за столь трогательную заботу о безопасности конкурирующих финансовых организациях.
http://www.banki.ru/bitrix/admin/index.php (на банки.ру у многоуважаемого представителя ВТБ24 рука видимо не поднялась :) ссыкотно стало)
Да, обновление платное, если кто не знал. Если вы хотите закрыть доступ к админке с определенных ip адресов, платите денежку.Разработчики Битрикса за Ваши деньги готовы закрыть их же «дыры» в их же обновлениях. Конечно же, у кого руки не из жопы и без обновлений закроет всё, но еще не известно чего они там в самом движке нафигачили. Пост на хабре, очевидно, преследовал определенные цели, конечно, он должен был вызвать резонанс, если уж меня задело. Это своего рода отповедь, типа не виноватые мы, смотрите что админы даже в финансовых организациях косячат, а что про газету говорить.. Да, я считаю, что пост именно битриксойдам и пренадлежит. Для чего? Все просто. Во-первых, это своего рода пиар, сайт МК на Битриксе ломанули и до народа стало необходимо донести, кто действительно виноват, или хоть бы повод для фин.управлений дать, чтобы они проплатили обновление cms, во-вторых – кто не захочет платить (авторы поста прекрасно догадываются, что у большинства админов и програмеров руки не из жопы), те сами закроют доступ по ip – таким образом авторы поста предупреждают о возможных брудфорсах и прочих каков-хаков, навязчиво намекая на «закройте ручками поскорей, а то как бы чего не вышло». Пост на хабре о возможности доступа к админским скриптам, без ограничений по ip, ставит под сомнение компетентность некоторых контор в области информационной безопасности, которые на предыдущих версиях фреймворка битрикс ставили свои одобрительные резюме. Вот на сколько я знаю, папка /domain.ru/bitrix в корне всегда была открытой. И кстати, при установке движок требует (сейчас не знаю, раньше до 6-го точно) 777 и 755 на файлы и директории при установке, ночной кашмар для админа. Так что думайте сами, решайте сами… философски: Предупреждён - значит вооружен! (с)
PS:
http://www.mti-bank.ru/netcat/ (боже-боже, памагите, вход на страницу авторизации без ограничения доступа по ip)
http://expostroy.ru/netcat/ (ужасные хакеры, могут срывать выставки государственного масштаба)
http://www.mir-tea.ru/_admin/ (тут сложнее, но хакеры могут продавать вместо чая "траву")
вот чесно, лень еще искать.. но на хабре мы имеем очередную заказуху. Лучше бы стоило признать, что любая система, имеет ли она доступ к админке по ip или нет, не является неуязвимой, вот и всё.
aklah.livejournal.com
Множественные уязвимости в последних версиях CMS 1С-Битрикс. Видео атаки
В своей работе по обеспечению ИБ сайтов, мы исследуем проблемы безопасности популярных в России систем управления веб-проектами. CMS 1С-Битрикс – является лидером в этой области, поэтому этой системе уделяется повышенное внимание.
Для актуального на сегодня исследования безопасности, была выбрана демо версия интернет-магазина, работающего на CMS 1С-Битрикс.
Исследование проводилось в виртуальной лаборатории 1С-Битрикс, предназначенной для онлайн тестирования функционала платформы.
Адрес лаборатории «1С-Битрикс: Управление сайтом»: http://bitrixlabs.ru. Не внося никаких изменений в процесс инсталляции, был «развернут» демо интернет-магазин, работающий под управлением 1С-Битрикс: Управление сайтом 16.5.4 по адресу: http://1071lab.bitrixlabs.ru/ Первым делом, было принято решение обновить решения до последней версии. После установки обновления (1С-Битрикс Решение «Современный интернет-магазин» версии 16.5.3), было начато исследование безопасности предложенного сайта.
Безопасность публичной части сайта «коробки» не вызывала нареканий и ранее, поэтому основное внимание было уделено административному разделу исследуемого сайта.
Множественные XSS
Наибольшее количество уязвимостей кода, позволяющих эксплуатацию непостоянных XSS атак были обнаружены в разделе «Дополнительные поля» административного раздела сайта:
Рабочий стол → Настройки → Пользователи → Список пользователей → Дополнительные поля → Настройки поляАдрес:
http://1071lab.bitrixlabs.ru/bitrix/admin/userfield_edit.php
В этом разделе, система предлагает создавать пользовательские поля для следующих типов данных: «Видео», «Привязка к элементам highload-блоков», «Строка», «Целое число», «Число», «Дата со временем», «Дата», «Да/Нет», «Файл», «Список», «Привязка к разделам инф. блоков», «Привязка к элементам инф. блоков», «Шаблон», «Опрос», «Содержимое ссылки».
Уязвимыми для XSS атак обнаружены поля формы для создания типов данных «Видео» и «Список».
Форма:
<form method="POST" action="/bitrix/admin/userfield_edit.php?lang=ru" enctype="multipart/form-data" name="post_form">Уязвимые поля для типа данных «Видео»
Поле input, вариант проверки возможности эксплуатации XSS:
"><script>alert(document.cookie)</script>| N | Название поля | name |
| 1 | Размер буфера в секундах | SETTINGS[BUFFER_LENGTH] |
| 2 | Уровень громкости в процентах от максимального: | SETTINGS[VOLUME] |
| 3 | Размеры (Ш х В, px) | SETTINGS[WIDTH] |
| 4 | Размеры (Ш х В, px) | SETTINGS[HEIGHT] |
| 5 | Цвет фона панели управления: | SETTINGS[BGCOLOR] |
| 6 | Цвет элементов управления | SETTINGS[COLOR] |
| 7 | Цвет эл. управления при наведении указателя мыши: | SETTINGS[OVER_COLOR] |
| 8 | Цвет экрана: | SETTINGS[SCREEN_COLOR] |
| 9 | id="bx_player_skin_input" (скрытое поле) | SETTINGS[SKIN] |
Поле textarea, вариант проверки возможности эксплуатации XSS:
</textarea><script>alert(document.cookie)</script>| 10 | Дополнительные переменные | SETTINGS[FLASHVARS] |
| 11 | Дополнительные переменные Silverlight: | SETTINGS[SILVERVARS] |
Уязвимое поле для типа данных «Список»
Поле input, вариант проверки возможности эксплуатации XSS:
"><script>alert(document.cookie)</script>| 12 | Подпись при отсутствии значения: | SETTINGS[CAPTION_NO_VALUE] |
На действия администраторов сайта (входящих в группу «Администраторы [1]») фильтр проактивной защиты Битрикс не распространяется, поэтому эксплуатация XSS атаки возможна без каких-либо ограничений.
Предполагая вопрос по поводу получения данных «защищенной» http-only cookie PHPSESSID: данные этой cookie не требуется для успешной эксплуатации атаки. Приведенный ниже пример успешной эксплуатации связки XSS + CSRF на «1С-Битрикс: Управление сайтом» подтверждает факт того, что использование http-only cookie нельзя рассматривать как полноценную защиту от XSS атак.
Эксплуатация CSRF атаки.
В процессе проведенного исследования, мы обратили внимание на возможность получения CSRF токенов, в разделе настроек пользователей (в т.ч. администраторов) системы:
Административный раздел сайта: Рабочий стол → Настройки → Пользователи → Список пользователейАдрес сайта: (на момент тестирования) http://1071lab.bitrixlabs.ru/bitrix/admin/user_edit.php?lang=ru&ID=1. К примеру, в случае смены пароля, или каких иных учетных данных администратора, данные отправляются на обработчик следующим образом:
POST /bitrix/admin/user_edit.php?ID=1&lang=ru HTTP/1.1 Host: 1071lab.bitrixlabs.ru User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Referer: http://1071lab.bitrixlabs.ru/bitrix/admin/user_edit.php?lang=ru&ID=1 Cookie: PHPSESSID=fdtc1nha7vd6fsgq9spuih4na0; BITRIX_SM_SOUND_LOGIN_PLAYED=Y; BITRIX_SM_GUEST_ID=1; BITRIX_SM_LAST_VISIT=13.01.2017+08%3A14%3A53; BITRIX_SM_SALE_UID=a44218257184b130c660695f7132ea02; BITRIX_CONVERSION_CONTEXT_s1=%7B%22ID%22%3Anull%2C%22EXPIRE%22%3A1484351940%2C%22UNIQUE%22%3A%5B%22sale_payment_add_day%22%5D%7D Connection: keep-alive Content-Type: multipart/form-data; boundary=---------------------------81949277201 Content-Length: 9588 -----------------------------81949277201 Content-Disposition: form-data; name="autosave_id" 20247bf0249c12c0e2f15effa95c29d52 -----------------------------81949277201 Content-Disposition: form-data; name="TITLE" -----------------------------81949277201 Content-Disposition: form-data; name="NAME" Bitrix -----------------------------81949277201 Content-Disposition: form-data; name="LAST_NAME" Team -----------------------------81949277201 Content-Disposition: form-data; name="SECOND_NAME" -----------------------------81949277201 Content-Disposition: form-data; name="EMAIL" [email protected] -----------------------------81949277201 Content-Disposition: form-data; name="LOGIN" admin -----------------------------81949277201 Content-Disposition: form-data; name="NEW_PASSWORD" admin12345 -----------------------------81949277201 Content-Disposition: form-data; name="NEW_PASSWORD_CONFIRM" admin12345 -----------------------------81949277201 Content-Disposition: form-data; name="XML_ID" --- Множество различных данных --- -----------------------------81949277201 Content-Disposition: form-data; name="sessid" aa4c42ead8583afbd067d0409d1b25b0Единственными валидируемыми данными (полагаю, что это и есть CSRF токены) для этого запроса являются:
«autosave_id» и «sessid», которые элементарно получить с помощью JS:
В качестве примера, можно привести «тестирование» на XSS, вышеописанных полей.
"><script>alert(phpVars['bitrix_sessid'])</script> 
Для того, чтобы взломать сайт на CMS 1С-Битрикс, эксплуатируя XSS+CSRF, достаточно сделать вектором атаки запрос, который, к примеру, изменит учетные данные доступа администратора сайта, или добавит нового, созданного атакующим.
Для подтверждения вышеописанного способа атаки на сайт, мы создали «боевой» JS скрипт, эксплуатирующий недостатки в разработке системы, и протестировали его работоспособность атаки на практике, в виртуальной лаборатории 1С-Битрикс.
Скрипт успешно «отработал», поставленную перед ним задачу. Итогом работы стала смена имя пользователя, пароля и почты администратора сайта. Авторизация в административной части «нового» администратора прошла успешно.
Вектором атаки является обычный POST XMLHttpRequest к /bitrix/admin/user_edit.php.
По понятным причинам, POC по эксплуатации вышеописанной техники атак на сайты, работающих под управлением «1С-Битрикс: Управление сайтом» в статье предоставлен не будет.
Вся информация по вышеописанной проблеме безопасности (включая вектор атаки) была передана в компанию Битрикс 19 сентября 2016 года. На 16 января 2016 года, уязвимости административного раздела CMS 1С-Битрикс версии 16.5.4 не устранены.
Дополнение:
На сегодняшний день, виртуальная лаборатория 1С-Битрикс предлагает к тестированию решения на CMS 1С-Битрикс 16.5.4. Ядро платформы в виртуальной лаборатории 1С-Битрикс, путем нехитрых манипуляций, можно обновить до версии 16.5.8.
В редакции 1С-Битрикс: Управление сайтом 16.5.8 вышеописанные XSS устранены, но проблемы безопасности, особенно в плане эксплуатации CSRF атаки, остались прежними. Проблемы с XSS также никуда не делись.
К примеру, эксплуатация вышеописанной угрозы возможна через уязвимые поля раздела: «Создать курс валют» → «Настройки курса» по адресу:http://1071lab.bitrixlabs.ru/bitrix/admin/currency_rate_edit.php?lang=ru&filter=Y&set_filter=Y Уязвимыми к XSS являются следующие поля формы:
<form method="POST" action="" name="rate_edit">| N | Название поля | name |
| 1 | Номинал | RATE_CNT |
| 2 | Курс | RATE |
Реализация самой атаки в реакции 1С-Битрикс: Управление сайтом 16.5.8 осталась прежней.
Видео по теме:
Видео лучше смотреть в «полный» экран.
Вопросы по конструкции XSS атаки
Способов эксплуатаций XSS атак множество. Техники их проведения и конструкции подробно описаны во множестве статей, которые легко найти в Сети.
Что касаемо предложенной атаки, то для ее успешной эксплуатации придется решить один вопрос с токеном sessid, защищающего форму. Этот вопрос решаем.
В качестве примера, для версий платформы, предлагаемых в виртуальной лаборатории 1С-Битрикс, это значение можно получить запросом: http://1028lab.bitrixlabs.ru/bitrix/components/bitrix/pull.request/ajax.php (1028lab.bitrixlabs.ru – новый адрес предоставленного к тестированию ресурса)
Ответ будет выглядеть следующим образом:
{'BITRIX_SESSID':'47f51fa0d098862e588033cdc8d39388','ERROR':'SESSION_ERROR'}
Существуют и иные способы получения этого токена. Все зависит от конкретного ресурса, сервера, его настроек и т.п.
Предвосхищая вопросы по CORS 'Access-Control-Allow-Origin' или Сross-Origin Framing – в этой статье, как и в комментариях, эти вопросы обсуждаться не будут, как и дальнейшее обсуждение конструкции полноценной атаки.
Основной целью этой статьи является обеспечение безопасности сайтам на платформе 1C-Битрикс, а не создание полноценной инструкции по их взлому.
К сожалению, вышеописанные уязвимости платформы, успешно эксплуатируются хакерами. Начиная с осени прошлого года, в нашу компанию inSafety, стали поступать обращения клиентов с проблемой взломов их сайтов.
Разбирая инциденты, мы обнаружили вышеописанные проблемы безопасности платформы 1С-Битрикс.
Защита от вышеописанной XSS + CSRF атаки
Компания Битрикс не приветствует модификацию системных файлов платформы, поэтому единственным вариантом защиты, может стать ограничение доступа по IP к файлам, расположенным в директориях /bitrix/admin/.
Понимая, что такой «радикальный» способ защиты может быть применим далеко не ко всем сайтам, вторым вариантом можно рассмотреть ограничение доступа к /bitrix/admin/. путем установки дополнительной парольной пары по типу Basic Authentication
Заключение
Обнаруженная проблема – является максимальной угрозой для сайтов, созданных на платформе «1С-Битрикс: Управление сайтом».
Эксплуатация XSS атаки, в случае ее грамотного исполнения, гарантирует взлом практически любого сайта, работающего под управлением CMS 1С-Битрикс последних версий.
Эксплуатация XSS атаки в связке с CSRF позволяет:
— изменять любые учетные данные доступа пользователей сайта— создавать новых пользователей сайта, с различными привилегиями— изменять привилегии существующих пользователей сайта
В отдельных случаях, особенно для ресурсов с недостаточным уровнем защиты на уровне сервера, возможна эксплуатация CSRF в чистом виде, без ХSS. Кроме того, вышеописанная атака делает обычную XSS (к примеру, в строке поиска, что часто встречается у сайтов на 1С-Битрикс) максимальной угрозой безопасности сайта.
Резюме
1. Не оставляйте открытым доступ к авторизации административного раздела сайта.2. Обновляйте ядро платформы 1С-Битрикс, специалисты компании устраняют уязвимости по мере их обнаружения.3. Хотя бы раз в год проводите аудит безопасности ваших интернет проектов, для предотвращения взлома и атак.
Разбираться с последствиями взлома всегда сложнее и затратнее, чем предупредить его.
Важно понимать, что эксперименты с безопасностью чужих сайтов, не говоря о эксплуатации атаки в криминальных целях, может повлечь уголовную ответственность. Вся информация по угрозе безопасности сайтов, в этом посте, предоставлена с целью повышения общего уровня ИБ конечных продуктов на платформе 1C-Битрикс.
Автор: inSafety
Источник
www.pvsm.ru
Взлом 1с битрикс: безопасный хостинг
Безопасность сайта складывается из трех вещей:- безопасности программной части (CMS, скриптов)
- безопасности сервера (хостинга)
- осведомленности и аккуратности администратора сайта или тех, кто работает с сайтом как администратор
Если все три составляющих организованы надлежащим образом, то сайт будет неприступным для хакеров и вирусов.
Надежность программной части
Программная часть — это система управления сайтом (Joomla, WordPress, Bitrix и др) или скрипты, на которых работает сайт. Надежность программной части подразумевает отсутствие уязвимостей («дыр»), позволяющих злоумышленнику получить доступ к базе данных, файловой системе или панели администратора сайта.
Продление демо битрикс
Чтобы в программной части не было уязвимостей, разработчики должны разрабатывать скрипты с оглядкой на безопасность, что выполняется не всегда. Правда жизни такова, что практически в каждой CMS или в скрипте существуют уязвимости. Часть из них опубликована в открытом доступе (публичные уязвимости), другая не доступна широкой аудитории и используется злоумышленниками для целевых атак на сайты. Для того чтобы программная часть сайта была надежна и неприступна, нужно уделять внимание проблеме безопасности.
Если сайта работает на одной из популярных систем управления сайтом, нужно следить за обновлениями и патчами, и своевременно обновлять CMS до самой последней доступной версии.
Если сайт работает на скриптах собственной разработки, нужно выполнить сканирование сайта доступными средствами поиска уязвимостей (XSpider’ом, Acunetix Web Vulnerability Scanner’ом, утилитами для поиска SQL иньекций, XSS, RFI и другими), проверить исходный код сайта средствами статического анализа исходного кода (RIPS) и, если обнаружатся уязвимости, исправить их. Кроме регулярных обновлений скриптов и CMS есть еще один важный момент, усиливающий безопасность и надежность скриптов — это правильная конфигурация сайта. Необходимо:
- грамотно прописать права на файлы и директории
- закрыть доступы к внутренностям сайта (каталогам с резервными копиями, конфигурационным файлам и пр)
- запретить выполнение скриптов в директориях загрузки
- поставить дополнительную защиту на вход в панель администратора
- и др.
Данные меры позволяют значительно снизить вероятность взлома сайт, даже при наличие уязвимостей в программной части.
Безопасность сервера (хостинга)
Вторым важным моментом, влияющим на безопасность сайта в целом, является хостинг, на котором размещается сайт. Хостинг может быть shared («общий») или dedicated («выделенный»).
Для shared-хостингов ответственность за безопасную настройку сервера лежит на администраторе хостинг-компании. Для dedicated-сервера (VDS/VPS/DDS) эта ответственность лежит на владельце сервера.
Как в случае shared-хостинга, так и в случае dedicated-сервера конфигурация должна обеспечивать минимальную свободу действий, не нарушающих работоспособность сайта. То есть на сервере должны быть разрешены только самые необходимые функции, а все остальное — запрещено. Например, если сайт не выполняет внешних подключений к другим серверам, должны быть отключены опции внешних соединений. Если сайт не использует системные вызовы (system, shell_exec, и др), эти функции необходимо отключить. Кроме того, должна быть ограничена область видимости файловой системы из скриптов и многое другое.
Обо всем этом должен позаботиться системный администратор сервера.
Как известно, на одном сервере shared-хостинга размещаются сотни сайтов, и каждому сайту требуются свои функции. Поэтому хостинг-компании максимально лояльно подходят к вопросам настроек сервера, разрешая практически все. Естественно, это сказывается на общем уровне безопасности всех сайтов, размещенных на их серверах. Поэтому владельцу сайтов нужно тщательно подходить к вопросу выбора хостинга: выбирать нужно тот, который позволяет производить настройку веб-сервера и php персонально для эккаунта, а не использовать установки по-умолчанию.
Настройку dedicated-сервера должен проводить опытный системный администратор, который изолирует сайт от остальной части системы, максимально ограничит свободу скриптов и область их видимости, а также организует механизмы контроля целостности файловой системы, систему резервного копирования и логгирования.
Осведомленности и аккуратности администратора сайта
Владельцы сайта, обычно, уделяют мало внимания вопросам безопасности, предполагая, что программная часть безупречна, настройки сервера надежны и безопасны. Хотя собственная беспечность наиболее часто является причиной взлома сайтов и заражения вирусами.
Ниже приведен чеклист, который должен постоянно держать в голове администратор (владелец) сайта:
- Компьютер, с которого выполняется работа с сайтом, должен быть защищен коммерческим антивирусным программным обеспечением и регулярно им проверяться. Если с сайтом работает несколько человек, данное требование применяется к каждому.
- Пароли от ftp/ssh/панели администратора нужно менять регулярно, хотя бы раз в месяц
- Не хранить пароли в программах (ftp-клиентах, браузере, электронной почте)
- Ставить сложные пароли вида «Xhsdf3@4%4»
- Работать по безопасному протоколу SFTP или SCP
Итог
Чтобы сайт был защищен от вирусов и хакеров, нужно достаточно много внимания уделять проблеме безопасности: поддерживать программное обеспечение в актуальном состоянии, правильно настраивать хостинг и следить за доступами к сайту. Если хотя бы один из трех элементов будет слабым звеном, сайт останется уязвимым.
—
По вопросам защиты сайта вы всегда можете обратиться к специалистам.
rpilot62.ru
Битрикс. Закон. Ответственность. | Nulled Warez Scripts
Вот - ткнули носом, посчитал нужным показать всем
Читаем - думаем.Добрый день.
В Комиссии на рассмотрении находится жалоба от Ассоциации "Русский Щит" на нарушение авторских прав компании ООО "Битрикс" (члена Ассоциации). Дело касается распространения нелегальной (с исходниками) версии программы "Битрикс. Управление сайтом." (государственная регистрация продукта в Федеральном Депозитарии Электронных Изданий НТЦ "Информрегистр" Федерального Агентства по Информационным Технологиям № 0320400770, правообладатель ООО "Битрикс", член Ассоциации "Русский Щит"), при этом в качестве физического сервера для распространения используется варез-компас softkiller.net:
http://softkiller.net/modules.php?name=News&file=view&news_id=1261http://serials.softkiller.net/file/index.php 1 bsm5.zip 30,041,396 17-10-2006 16:47 BSM5 from DOKTER[M.O.F.] softkiller.net Размер: 30,041,396 байт, скачан: 9 раз
Действия лица, разместившего данные файлы, по российскому законодательству подпадают под состав статьи 146 часть 3 УК РФ (предусматривающую по практике применения штраф, конфискацию аппаратуры, судимость и условный срок). Естественно, что это также нарушение правил хостинга компании Epolis (мы давно и плотно работает с Евгением, и не так давно обсуждали как раз вопрос по Битриксу), законодательства РФ в области охраны авторских прав и положений закона "О Связи".
Возможно, что Вы допустили подобную ситуацию по незнанию, или из-за неверия в наступление ответственности. В таком случае Вам необходимо удалить данный файл и новость и не допускать нарушений авторских прав компаний, членов Ассоциации "Русский Щит" (так поступают большинство крупных варез-компасов, такие так nnm.ru, vanix.net, 2baksa.net, nht-team.ru и пр). Иначе речь будет идти о том, что сайт softkiller.net находится в пограничной зоне, т.к. летом 2004 года вступила в силу новая редакция закона об авторском праве, статья 48.1.2.2 которого впрямую запрещает рекламирование, обсуждение и оказание любых услуг (в том числе и информирование общественности) по любым устройствам и средствам снятия технических средств защиты. Ситуацию упрощает и то, что незаконные файлы Вы храните на своем сервере.
Жду ответа. Все координаты внизу. Я уполномочен действовать и отвечать на вопросы от имени Комиссии, и от имени Ассоциации "Русский Щит". О том, как работает Комиссия и Ассоциация в случае выявления нарушений можно узнать в интернете, через yandex и другие поисковики (набрав, например "яшин комиссия интернет 146").
В случае необходимости данное письмо будет направлено Вам официально, на бланке Комиссии с подписью и печатью руководства. Связаться со мной можно по данному е-майлу либо по рабочему телефону (495) 741-3704 (с 10 до 18 по Москве). Если приведенные факты вызвали у Вас вопросы, задать их также можно по емайлу.
-- Олег Вадимович Яшин, отв. секретарь Комиссия по безопасности информационного рынка Совет Предпринимателей при Мэре и Правительстве Москвы +7 (495) 741-3704, mailto:[email protected] 121205, Россия, Москва, Новый Арбат, 36
________________________http://softkiller.net/modules.php?name=News&file=view&news_id=1261
по теме: http://infostore.org/info/230697 http://www.appp.ru/novosti/21-02.htm http://www.appp.ru/novosti/30-05.htm
www.nulled.cc
Помощь - Битрикс, защита от вирусов/взлома | Страница 2
Скажу вам одно, изучайте как правильно настраивать сервера, про уязвимости битрикса промолчу, а вот о серверах вы все как-то забываете. Многие VPS-VDS и т.п. один раз сервер построили и успокоились, а если учесть, что многие живут "в комуналках", которые годами не обновляются, и сломав вашего соседа, вы просто идете в нагрузку бонусом. При определенных запросах можно вытянуть с сервера почти все что угодно и это даже не взлом — ведь на сервере ничего не меняется, просто сервер начинает сам, как умолишонный, раздавать все, что от него не требуется. Если вы экономите, потом не нойте, что у вас траффик сливается налево-направо, у вас украли пользователей и т.д.Добавлю к словам lexnekr, приватные уязвимости действуют годами и о них никто не знает и не узнают еще не один год! И только случайно открываются отдельными пытливыми исследователями! Тут уже зависит от исследователя, он либо об этом поведает всему миру, либо будет использовать для общества, либо в корыстных целях лупить бабло — ненужное зачеркнуть.И просто добавлю. Никогда! не экономьте на сервере и нормальном администраторе, если не справитесь с работой сами, заключайте договор о финансовой и любой другой ответственности, не покупайте виртуальные хосты, виртуальные сервера — только железный сервер! Благо, что есть Лизавеб, Хетзнер, да и любые другие провайдеры — предлагают за адекватные цены железки на аукционах. При определенных условиях, почти в любом провайдере, можно завладеть любым виртуальным дроплетом.
Помните об этом! И меняйте все уже завтра — сервер, ленивого толстого админа, пусть на аутсорсе, но подпишите договор. Обновляйте сервера, используйте двухфакторную авторизацию, базовую авторизацию на админку, удаляйте с своего сервера любые фреймворки по управлению базами данных (если нужно использовать, загрузите, попользуйте, удалите-переместите), научитесь читать логи раз в неделю, фильтрация логов позволит сократить рутинный текст до 20-30 аномальных строк, покупайте обновляемый антивирусник — защищайте свои данные!
Ленивый даже не узнает, что его рип сайта продали +100500 раз за 1000-5000 рублей и его рип окупился лучше чем его вложения в старт бизнеса. Как-то так
nulled.in
