Opencart защита от вирусов
OpenCart – как и некоторые другие CMS – можно назвать относительно защищенной платформой. Однако, как и в случае с другими системами управления контентом, лучше сразу позаботиться о безопасности и защите своего сайта от взлома посторонними лицами. В этой статье я дам основные советы, которые помогут вам повысить уровень безопасности вашего сайта. В первую очередь статья подойдет тем, у кого есть свой интернет-магазин, сделанный на базе OpenCart, но, с другой стороны, советы достаточно универсальны, поэтому будут интересны владельцам сайтов на других CMS.
1. Сокрытие входа в административную панель
По умолчанию для того, чтобы войти в панель администратора, обычно используется такой путь: ваш_сайт.ru/admin. Естественно, чем больше информации будет у хакеров, тем легче им будет взломать ваш сайт. Поэтому первая рекомендация – нужно изменить адрес входа в административную панель с /admin на другой: /manager, /panel или что-то еще более сложное.
Как это сделать: в файловом менеджере или в phpMyAdmin, во-первых, измените название папки “admin” на другое; во-вторых, сделайте такую же замену в файле config.php внутри папки, которую вы переименовали; в-третьих, иногда изменения надо внести в файл config.php в корневой папке (проверьте, есть ли там упоминание admin).
Если все сделано правильно, то теперь административная панель будет доступна по новому адресу – главное, не забудьте его.
2. Изменение логина администратора (и пароля)
После изменения адреса для входа в панель стоит задуматься и об изменении логина, который по умолчанию выглядит тоже как admin. Надо отметить, что это вообще основной логин, который обычно используется на многих CMS, поэтому даже если у вас магазин или сайт не на OpenCart, все равно советую его незамедлительно поменять.
Кстати, тут же вы можете поменять и пароль – настоятельно рекомендую сделать это, придумав пароль не короче десяти символов. Если не можете придумать сами, воспользуйтесь одним из онлайн-сервисов по генерации паролей, которые легко можно найти в Гугле или Яндексе.
Внимание! Не используйте повторяющиеся пароли! Каждый пароль должен быть индивидуальным, ни в коем случае не ставьте для входа в панель администратора такой же пароль, как и, к примеру, для входа в почту.
3. Изменение прав доступа для важных файлов
Можно выставить там цифрами 444 (только чтение для владельца и для всех остальных), либо отметить ползунками эти же параметры.
Также можно воспользоваться FTP-клиентом – например, Filezilla – и выставить права доступа там.
4. Отказ от отображения ошибок
Как правило, при взломе хакеры используют разные лазейки, и в этом им часто помогают сообщения об ошибках, которые отображаются на неправильные действия. Поэтому рекомендую отказаться от отображения этих ошибок.
Тут у вас, скорее всего, возникнет вопрос, а что делать, если нужно посмотреть ошибки? Для этого можно использовать файл журнала ошибок (его название есть в этом же блоке в настройках).
Посмотреть его вы можете, если зайдете в корневую папку сайта, затем в system и затем в logs.
5. Добавление связки слов для входа в панель администратора
Как и в остальных случаях, в первую очередь это усложнит взлом вашей панели административной панели. Однако данный способ более сложный, чем остальные, так как предусматривает работу с кодом.
Как это сделать: в файловом менеджере вам нужно найти и открыть файл login.tpl. Вы найдете его по такому пути: public_html/admin/view/template/common/login.tpl
(Если вы ранее уже поменяли название папки admin на другое, то в этом пути также замените его на нужное.)
Далее вам нужно в самый верх файла скопировать следующие строки:
Но это не вся работа, которую необходимо выполнить в этом файле. Вам необходимо слова “secretkey” и “secretkeyvalue” заменить на другие (произвольные). Делать это нужно очень аккуратно, без удаления и исправления других знаков. При этом вам обязательно нужно запомнить эту пару слов, иначе вы не сможете попасть в панели администратора своего сайта.
После этого в самый конец файла вам нужно добавить:
Теперь для того, чтобы зайти в панель администратора, вам нужно использовать ссылку такого вида:
Возвращаемся к тому, что если выше вы уже переименовали папку admin, то в эту ссылку вам вместо admin нужно поставить то название, которое вы дали этой папке. Только в этом случае вам откроется страница, куда нужно ввести данные для авторизации в панели администрирования.
Еще одно действие, которое нужно выполнить дополнительно к этому, - это запретить поисковым сервисам индексировать страницу для авторизации.
Перейдите в ту директорию, которая уже упоминалась выше (где находится login.tpl), и откройте файл header.tpl. После тега , ниже добавьте строчку:
Теперь поисковые роботы не будут индексировать эту страницу. Если до этого в файле robots.txt вы писали что-то вроде Disallow: /admin (для того, чтобы запретить индексацию этой страницы), то удалите эту запись. Не забывайте, что robots.txt – это доступный всем файл, который могут посмотреть все, в том числе и взломщики. Поэтому писать там адрес панели администрирования не следует.
sites, coding, joomla, wordpress, opencart, ocstore, сайтостроение, интенет-магазины, безопастность в сети
Здравствуйте, дорогие Читатели IT-блога balamarin! Сегодня я — Balamarin расскажу о моем опыте по защите интернет — магазина на платформе OpenCart.
Честно говоря, сразу скажу, что пошел изначально не по тому пути, начав искать посты на разных форумах, натыкался на разные статьи про права доступа со совершенно дикими советами поставить на файл config.php права 777.
Но в итоге мне удалось все же нарыть очень годную статью, которая в принципе может подойти для любой CMS.
Далее я скопирую данную статью и представлю ее вашему вниманию здесь в блоге Balamarin!
Защита Opencart.
Сегодня мы рассмотрим немаловажный вопрос: как защитить свой магазин от взлома и проникновения?
1. Одно из глобальных изменений, осуществляемых для защиты магазина на OpenCart, является скрытие админ-панели от посторонних глаз. Что это значит и как это сделать?
Сделать это довольно просто:
· Папке admin даем новое, никому не известное название;
· Открываем файл config.php в корневой папке магазина и в путях вместо admin указываем название нашей новой папки (изменения будут внесены всего в один путь);
· Аналогично поступаем с файлом config.php, который находится в вышеупомянутой папке admin — меняем в путях admin на наше новое название (5 ссылок нуждаются в изменении).
2. Второй шаг защиты заключается в логине: никогда не оставляем для входа в админ-панель такой логин, как admin. Нет более доступного и общеизвестного логина чем admin, так что если при установке OpenCart, мы не изменили логин на более сложный, то это не поздно сделать сейчас. Самый простой способ сменить логин — это зайти в Aдмин-панель/Система/Пользователи и задать новый логин.
3. Также поступаем и с паролем — создаем или меняем на сложный и замысловатый, используя не менее 10 знаков, желательно разного регистра и с использованием спец. символов типа $, %, &, ^ и т.д.
Смену пароля осуществляем все из той же админки /Система/Пользователи.
4. E-mail+пароль и e-mail+админ-панель. Большинство магазинов в контактах помимо формы обратной связи также указывают один или даже несколько почтовых ящиков для связи. И необходимо помнить о том, что пароль для входа в админ-панель и пароль к почте должны быть разными, никогда не используйте один и тот же пароль для столь важных разделов вашего магазина. Ведь именно почтовый ящик является хранилищем информации о поступивших/оплаченных заказах с персональными данными ваших покупателей.
5. Обезопасим важные файлы: config.php и admin/config.php. Эти файлы содержат в себе весьма важную информацию: доступ к БД. По этой причине следует установить правильные права доступа к этим файлам: 0444 (только чтение).
Права на папки устанавливаем либо через хостинг (cPanel)/ либо через ftp-клиент, который обычно используем для загрузки файлов на сервер.
Вот на таком количестве способов защиты магазина на OpenCart мы пока что и остановимся. Может их не так уж и много, они незамысловаты, но, к счастью, действенны. Существуют еще варианты ограничения доступа к админке магазина и доступа по ftp через указания ip адреса, но эти изменения стоит вносить лишь в том случае если ваш ip адрес постоянный, иначе могут возникнуть проблемы с доступом к сайту. Если же кому-то будет интересен и этот способ защиты, то дайте знать и пост будет дополнен.
.htaccess и .htpasswd
Если возвращаться к истокам (а в нашем случа истоки безопасности opencart — это его докуменнтация) то можно сказать о двух небезызвестных файлах .htaccess и .htpasswd.
Можно организовать на своем сайте Базовую или Digest аутентификацию. Я опишу только Digest — аутен. так как она , на мой взгляд наиболее безопасна.
Для использования данной программы вам потребуется небольшое знание англиского
Каждая из программ использует дефолтные файлы , входящие в пакет Apache, такие как:
Вот ссылка на эти программы(SourceForge.net): Htpassword-generator_by_balamarin
пароль: balamarin
Для создания файла с паролями я написал 2 небольшие программы. Первую для Basic-аутентификации, а вторую для Digest-аутентификации. Перейду сразу к Digest.
Digest-аутентификация.
Digest-аутентификация представляет собой более продвинутый и сложный вид аутентификации, чем Basic-аутентификация. Главным отличием здесь является то, что логин-пароль пользователя пересылаются через сеть не в открытом виде, а шифруются по алгоритмуMD5. Настройка Digest-аутентификации похожа на настройку Basic-аутентификации. Основные шаги остаются прежними:
Доступ к ресурсу site будет иметь только пользователь balamarin
3) Создать файл для работы с группами и настроить групповой доступ (этот пункт не является обязательным).
Создаем файл .htgroups следующего содержания:
4. Прячем файл паролей от посторонних глаз
Теперь файл скрыт от сторонних пользователей — от всех кроме компьютера с ip:
Еще раз о скрытии админской панели
Здесь написан один из возможных способов защиты админки магазина от не прошенных гостей.
Она заключается в том, чтобы для входа в панель администратора необходимо правильно указать адрес.
Если вы входите как
То после внесения изменений придется входить так:
Теперь приступим к изменению кода.
Зашита с помощью программы ultimate opencart protection
Вот она, весна — время депрессий, мартовских котов и дождей. Делать что-либо
совсем не было желания, но, как назло, у меня освободилась пара вечеров. Терять
это драгоценное время очень уж не хотелось, поэтому я решил потренировать глаза,
покопавшись в PHP-движках. Ну, а вдруг чего выгорит? Чтобы узнать, что же
все-таки вышло из комбинации OpenCart, пары вечеров и пары литров кофе, читай
дальше.
Дело было вечером
Принялся я за поиски уязвимостей, накачав самых разных движков последних
версий. В процессе изучения оных остановился на движке онлайн-магазина OpenCart
версии 1.4.6. Запустил самопальный баш-скрипт для поиска подозрительных функций.
Среди всего прочего кода, который выдал скрипт, мое внимание привлекла следующая
строка:
Ну-ка глянем, что там у медвежонка внутри. Этот подозрительный кусок кода
находится в файле system/helper/dompdf/include/dompdf.cls.php, на строке 276 —
туда и направимся. Открываем файл и видим, что находимся внутри метода load_html(),
который принимает переменную $str, и на данном этапе она никак не фильтруется.
Но, так как в этом файле находится только один класс, нам надо найти точку
вхождения — скрипт, который доступен извне и работает с классом DOMPDF. Уровнем
выше, в самой папке dompdf, лежат разные скрипты; начнем перебирать их в
браузере. Открываем первый попавшийся, а это dompdf.php! Видим, что скрипт
ругается, мол, не хватает ему входных параметров. Из ошибки понятно, что ему
нужно получить $_GET['input_file']. Ну что же, удовлетворим его, но
предварительно посмотрим, что находится внутри самого скрипта. А внутри —
мешанина всяких условий. Чтобы узнать, как далеко скрипт выполнился, я обычно
расставляю в самых разных местах отладочные сообщения типа:
printf("File: %s, line: %d", __FILE__, __LINE__);
Немного помучив скрипт, я установил следующее: если указать требуемый
параметр input_file, то он попадает в метод load_html_file() класса DOMPDF. Этот
метод, в свою очередь, пытается прочитать файл в строку при помощи функции
file_get_contents(), а затем передает содержимое в метод load_html(). И
происходит все это без каких-либо фильтраций. То ли разработчики надеялись на
то, что пользователи этой библиотеки будут все фильтровать, то ли они очень
наивны и оставили все на волю судьбы. Как бы то ни было, это играет нам на руку.
Следуя логике работы скрипта, получается, что мы можем читать файлы. Проверим
это дело. В браузере я набрал:
О да, мы получили /etc/passwd в виде PDF-файла. Исходя из того, для каких
целей служит библиотека, этого можно было ожидать.
Пишем эксплойт
Читать произвольные файлы, пусть и в такой извращенной форме — это неплохо,
но хотелось чего-то большего. Уж очень сильно eval() мозолил глаза — нельзя
упускать возможность выполнить PHP-код. В этом случае было бы достаточно
заинклудить любой файл, содержащий код, и он бы успешно выполнился. Но в своем
эксплойте для этого движка я хотел сделать удаленное выполнение команд без
инклуда посторонних файлов. Начиная с версии PHP 5.2.0 поддерживается обертка
data:, которую и было решено задействовать. Протокол data был описан в
127 номере журнала,
так что обращайся туда, а мы едем дальше.
Как всегда, эксплойт я писал на своем любимом Perl. В целом, эксплойт будет
понятен и неискушенному в Perl человеку, но там я применил один трюк с башем.
Чтобы тебя не смущать, на всякий случай поясню следующую строку:
$cmd = encode_base64($cmd.'| sed -e :a -e \'$!N;s/\n/
/;ta\'');
В переменной $cmd содержится введенная тобой команда, допустим, ls -la.
Склеиваем ее с тем однострочником, что справа. Этот сниппет с sed я применил
лишь для того, чтобы преобразовать переносы строк в ‘
’, так как в
полученной PDF применяется HTML-форматирование. В итоге получится следующая
команда:
ls -la | sed -e :a -e '$!N;s/\n/
/;ta'
Через пайп передаем результат первой команды в sed, который занимается
форматированием. Все это добро мы перекодируем в base64 и вставляем в очередной
кусок кода.
Ну, а здесь тебе уже должно быть все понятно — очень похоже на пресловутый
PHP.
Сам эксплойт позволяет выполнять системные команды, а результат приходит в
виде PDF-файла. Тут я подумал: а что, если за меня уже сделали всю работу?
Совсем забыл погуглить на предмет наличия уязвимостей под этот движок. Поиск по
последней версии OpenCart ничего не дал, были лишь старые уязвимости. А вот по "dompdf
exploit" (это все-таки сторонняя библиотека) кое-что нашлось. Benj Carson из "YGN
Ethical Hacker Group" сообщал об уязвимости, которая заключается в том, что
можно скачивать любые файлы в виде PDF (что я и раскопал). Однако мой эксплойт
использует более широкие возможности уязвимости, к тому же, про уязвимость в
OpenCart сообщено не было.
А что, если.
Итак, эксплойт для движка был готов, но тут я вспомнил про одну вещь. Когда я
скачивал движок, то заметил, что сайт предоставляет онлайновую демо-версию.
Догадываешься, о чем я? Так точно, мы будем штурмовать оффсайт! Не всегда,
конечно, выпадает такое счастье как уязвимый движок на самом сайте разработчика,
но попробовать стоит. Кто не рискует, тот не пьет шампанское. Первым делом я
сразу полез проверять, что выплюнет уязвимый скрипт. В моем случае (на локальном
сервере) он ругался на неопределенные параметры. Но в демоверсии сайта вполне
может быть версия скрипта посвежей и без уязвимости, либо вообще отсутствовать
такой скрипт. Там часто в целях безопасности обрезают все, что только можно. Как
бы то ни было, идем по следующей ссылке:
Скрипт ругается точно также, как и на моем сервере. Это хорошо, можем
продолжать эксперименты. На тот момент была лишь одна идея — применить
свежевыжатый эксплойт. Набираем в консоли:
perl dompdf.pl -u=http://demo.opencart.com/-c='ls -la'
Смотрим результат в сохраненной PDF'ке. Открываем, а там ругаются: неверный
формат PDF-файла. Решил посмотреть, что же вообще сервер отдал в качестве
содержания файла. Переименовал файл в текстовик, а внутри ошибка PHP:
URL file-access is disabled in the server configuration in.
И бла-бла-бла. Это могло означать, что у них на сервере PHP сконфигурирован
как allow_url_fopen=off. При таком раскладе протокол data не работает, и,
естественно, RFI тут тоже не пройдет. Обидно, конечно, но меня это не остановило
— я решил искать другой способ заполучить шелл на оффсайте движка.
Кстати, на локальном сервере желательно иметь ту же конфигурацию, что и на
уязвимом, чтобы максимально приблизить обстоятельства локального тестирования к
реальным. Поэтому я и у себя выставил allow_url_fopen=off, чтобы в будущем не
наступать на грабли. Однако, когда тестируешь движки, стоит настраивать PHP на
самую мягкую конфигурацию.
Серия неудач…
Сначала я хотел посмотреть, как работает уязвимость на оффсайте движка. Вдруг
читать файлы вовсе не получится? Но чего гадать — набираем в браузере:
И скачиваем PDF-файл со списком пользователей системы. Неплохо, но это нам
мало поможет. Я принялся за поиски конфигурационных файлов в надежде найти
аутентификационные данные. Прямо в корне системы OpenCart лежит config.php. Но
имей ввиду, что, прежде чем скачивать PHP-файл, нам надо его во что-нибудь
преобразовать, иначе он просто выполнится как код. Значит, ядовитый URL
приобретает такой вид:
Здесь я использовал фильтр потока, который появился в PHP с версии 5.0.0.
Таким образом, прочитанный файл преобразуется в строку, закодированную при
помощи base64. Между прочим, хороший способ читать бинарники. Итак, используя
уязвимость, я успешно скачал содержимое файла в виде PDF. Раскодировав обратно
полученную строку, я получил следующее:
Теперь есть логин и пароль пользователя MySQL. Надо проверить сервер на
наличие открытого порта 3306. С забугорного дедика запускаю:
nmap 85.13.246.138 -p 3306
nmap сообщает о том, что порт открыт. С того же дедика пробуем:
mysql -h 85.13.246.138 -u opencart_user -p
У нас запрашивают пароль. Вводим его, но нас шлют лесом. Многочисленные
попытки с разных серверов, через разные прокси и разные методы не дают никаких
результатов: то неверный пароль, то непонятная каша вместо приглашения, то срывы
соединения. Обидно и непонятно. Облом номер один.
Затем мне пришла в голову одна идея. Если инклуд удаленных файлов и протокол
data запрещены, то что будет, если попробовать найти в демоверсии сайта загрузку
файлов? Нам бы пригодилась и загрузка картинок. Заинклудив картинку с PHP-кодом,
мы могли бы его выполнить. К сожалению, поиск по демонстрационной версии админки
не принес никаких результатов. Админка была урезана в правах и нельзя было
грузить даже картинки. Облом номер два.
Потом я решил взяться за врапперы PHP, поколдовать с ними — вдруг что
выгорит. Но все безрезультатно. Ситуация такова: удаленные файлы читать нельзя,
локальные файлы можно получить в виде PDF и можно выполнять PHP-код локальных
файлов. Но проку от этого всего нет, если нет возможности выполнить именно свой
код. Тогда я вспомнил про инклуд PHP-кода в локальные файлы. Но как я не
пытался, ни старый трюк с лог-файлами apache, ни метод с /proc тоже не
помогли. Это был облом номер три.
… но в итоге моя взяла
Все это начинало действовать на нервы — есть и уязвимость, и конфиг с паролем
к базе данных, но всюду меня шлют лесом. Оставив это дело на следующий день, я
отправился спать. Как говорится, утро вечера мудренее.
На следующий день я снова принялся курить мануалы по PHP и разгребать
уязвимую библиотеку. Вспоминая про обертки, фильтры и прочее, я вспомнил про php://input.
Эта обертка позволяет читать POST данные, и независима от каких-либо директив
PHP. В общем, затея моя была такова: вместо файла подставить данную обертку, а
нужный код послать в POST-массиве. В итоге строка запроса в эксплойте должна
быть такой:
Быстро набросав на коленке Perl-скрипт, я принялся тестировать этот метод. Но
был жутко огорчен. Данные, принимаемые из POST-массива, приходили как
закодированные URL-эквиваленты; к тому же полностью приходило как содержимое,
так и название переменной. То есть, получалось такое безобразие:
Понятно, что это не будет выполняться как код. Снова надо было думать и
искать альтернативные варианты, а ведь счастье было так близко.
В поисках методов модификации передаваемых значений через php://input я
набрел на метод PUT. Надо бы попробовать его — он проще, чем POST, но
поддерживается не всеми серверами и не всегда. Итак, заменив POST на PUT,
пробуем послать какую-нибудь строку, которая должна выполниться как PHP-код. И
что ты думаешь? Это прокатило, скрипт получает чистую строку, код выполняется.
Второй эксплойт основан на методе с PUT и php:/input, он загружает произвольные
файлы на сервер с уязвимой библиотекой, действуя в несколько этапов.
Вот кусок из эксплойта:
my $tmp_shell = $tophp;
В переменной $tmp_shell у нас временный мини-шелл. Его задача — загрузить
файл (для нас предпочтительно полноценный шелл) и удалить самого себя. Этот
мини-шелл будет записан в файл i.php при выполнении PHP-кода. В последней строке
у нас находится перловый запрос PUT. В принципе, тут все должно быть интуитивно
понятно. Этот и самый первый эксплойты ищи на
диске.
Таким образом, вырос второй эксплойт, ориентированный на вариант, когда
allow_url_fopen=off. На локальном сервере все замечательно работает, шелл
заливается. Теперь остается скрестить пальцы и запустить наш эксплойт против
демоверсии сайта. Снова соединяюсь со своим дедиком и запускаю оттуда эксплойт:
www-data@sd:/var/www/lib$ ./e.pl -u=http://demo.opencart.com/ -s=./logs.php
Как ты понимаешь, теперь мне повезло, и шелл залился. Находясь внутри
сервера, я увидел, что админы сервера поотрубали множество опасных функций PHP,
неплохо настроили PHP-конфиг, но это их не спасло. Изначально поставленная мною
цель была достигнута — преодолеть первый рубеж, залить шелл. Находясь на
сервере, можно было дампить базу данных, рутать сервер, дефейсить и так далее,
но это не входило в мои планы. Я поступил более гуманно, сообщив администраторам
об уязвимости. Админы подсуетились в тот же день, так что на оффсайте последняя
версия (1.4.6) не поддается эксплойту. Поэтому можно наткнуться как на
уязвимый, так и на чистый движок одной и той же версии.
Хэппи энд
Какой урок можно извлечь из этой истории? Атакующей стороне — не сдаваться и
не отступать, а шевелить мозгами и искать пути обхода. Как ты мог наблюдать, для
того, чтобы попасть на сервер, мне пришлось перебрать немалое количество разных
техник и методов эксплуатации уязвимостей. Что по поводу разработчиков, то есть
такая пословица: "доверяй, но проверяй". В движке, с которым мы работали, была
применена уязвимая сторонняя библиотека, что и стало причиной успешной атаки. А
ведь об уязвимости было известно еще до моего эксплойта. Это говорит о том, что
разработчики движка не интересуются безопасностью, не читают багтреки, да и
аудит своей системы в целом не проводят. В итоге финал таков, как он есть. Но
одно было сделано правильно. Сами исходники движка находятся на хостинге от
Google. Возможно, если хорошо поискать, то можно и на оффсайте найти
аутентификационные данные для хостинга проекта, но это уже потребует немного
больших усилий. Помимо безопасности, это снижает нагрузку на сервер, остается
больше места, не расходуется трафик. В общем, учись, не вреди и используй знания
в благих намерениях.
WARNING
Внимание! Информация представлена исключительно с целью ознакомления! Ни
автор, ни редакция за твои действия ответственности не несут!
Где-то в октябре прошлого года, я решил создать на будущие, собственный Интернет-магазин. Поскольку денег на покупку платного движка у меня нет, (да и не всегда стоит платить за те функции в платной CMS, которые есть в бесплатной), я решил выбрать для своих целей, платформу opencart.
Выбрал я именно эту платформу потому, что она:
- Совершенно бесплатная
- Наиболее известная среди бесплатных (наверное среди платных тоже)
- Хороший функционал
- Присутствует огромного количество как платных так и бесплатных модулей и шаблонов
- Я с ней достаточно хорошо знаком
Оригинальный дистрибутив называется opencart, а вот переделанная версия российский разработчиков — ocStore. Для своих целей, я выбрал ocStore, по той простой причине, что она более оптимизирована под СНД и в ней присутствую, еще другие полезные SEO-штучки.
Скачал я себе архив с CMS, скачал паблик шаблон + несколько модулей. Все это дело настроил как следует и забросил, так как и не планировал в ближайшее время, что-то делать с магазином, (да и с бесплатным шаблоном далек не уедешь).
Но буквально несколько дней назад, я совершенно случайно заметил, что магазин очень медленно загружается. Как позже показали разные инструменты, загрузка идет в течении 5-6 секунд, что в 21 веке — не позволительно. Все опробованные мною инструменты, ругались на долгий ответ сервера (от 5 сек.). Я конечно сразу стал ругать за это хостинг, но потом подумал: ведь другие сайты — работают нормально на этом хостинге — включая мой блог. Но все равно, решил написать в поддержку хостинга. На, что мне ответили: что проблему нужно искать в своем сайте.
Поиск Гугла — ничего не дал. Писал на разных форумах о своей проблеме, но там большинство пользователей, только отписывались, чтобы я менял хостинг, поскольку проблема именно в нем. Но я точно знал, что загвоздка в другом, так как пробовал ставить сайт на другой хостинг — проблема не решалась.
Я бы и так далее мучился, если бы мне на форуме CMS не порекомендовали посмотреть файл: system/librari/response.php и проверить на вредоносный код. Когда я открыл этот файл, то в самом конце я увидел следующие:
Кликните по картинке, для ее увеличения.
Этот набор не понятных символов, ничто иное, как закодированный код в base64, чтобы вебмастер не мог определить, что это вредоносный код. Этот код человек не может прочитать, но его прекрасно читают поисковые системы + ко всему, он может делать много разных вещей с вашем сайтом, вплоть до того, что оставлять ссылки и скачивать вашу базу данных.
Если раскодировать этот код, то мы получим такое:
Сайт долго загружался по той причине, что сайт который присутствует в данном коде, очень долго отвечает из-за этого и мой магазин долго грузился. Что делает этот код — я не знаю, но точно знаю 1: после замены файла response.php, на файл с оригинального дистрибутива — магазин начал нормально работать.
Давайте поразмышляем, откуда мог появится данный код в меня в CMS. У меня по этому поводу, есть несколько предположений:
- Я его скачал вместе с CMS. Что маловероятно, так как все уже было залатано.
- Мне его подсунул человек, которому я давал доступ для правки модуля под свои нужды. Эта идея имеет больше права на жизнь, но я тоже в это не очень верю.
- И последние, что наиболее вероятное, это то, что я скачал эту заразу вместе с шаблоном, или модулем с паблика.
Какие можно сделать с этого выводы?
Качайте модули и шаблоны только с сайта CMS opencart. Если очень хочется скачать с другого сайта, то после скачивания, не поленитесь проверить тот дистрибутив на вредоносный открытый и закодированный код.
Спасибо за то, что дочитали статью до конца!
Использование плагина безопасности защищает ваш сайт WordPress от вредоносных программ, атак и попыток взлома. В этой статье собраны лучшие плагины безопасности WordPress, которые рекомендовано использовать для защиты сайта.
Каждую неделю около 18,5 миллионов сайтов заражаются вредоносными программами. Средний сайт атакуют 44 раза каждый день, включая веб-сайты WordPress и других CMS.
Нарушение безопасности на вашем веб-сайте может нанести серьезный урон бизнесу:
- Хакеры могут украсть ваши данные или данные, принадлежащие вашим пользователям и клиентам.
- Взломанный веб-сайт можно использовать для распространения вредоносного кода, заражая им ничего не подозревающих пользователей.
- Вы можете потерять данные, потерять доступ к своему веб-сайту, сайт может быть заблокирован.
- Ваш сайт может быть уничтожен или поврежден, что может повлиять на рейтинг SEO и репутацию бренда.
Вы можете в любой момент отсканировать свой сайт WordPress на предмет нарушения безопасности. Однако очистка взломанного сайта WordPress без без профессиональной помощи может быть довольно сложной для начинающих веб-мастеров.
Чтобы избежать взлома, необходимо следовать рекомендациям по безопасности сайта. Одним из важных шагов по защите вашего сайта WordPress является использование плагина безопасности. Эти плагины помогают упростить безопасность WordPress, а также блокируют атаки на вашем сайте.
Давайте рассмотрим некоторые из лучших плагинов безопасности WordPress и как они защищают сайт.
Примечание. Вам нужно использовать только один плагин из этого списка. Наличие нескольких активных плагинов безопасности может привести к ошибкам.
Sucuri является лидером в области безопасности WordPress. Разработчики предлагают базовый бесплатный плагин Sucuri Security, который помогает вам укрепить безопасность и сканирует сайт на наличие распространенных угроз.
Но реальная ценность заключается в платных планах, которые поставляются с лучшей защитой брандмауэра WordPress. Брандмауэр помогает блокировать вредоносные атаки при доступе к WordPress.
Интернет-брандмауэр Sucuri отфильтровывает плохой трафик до того, как он достигнет вашего сервера. Он также обслуживает статический контент со своих собственных CDN-серверов. Помимо безопасности, их брандмауэр уровня DNS с CDN дает вам потрясающее повышение производительности и ускоряет работу сайта.
Самое главное, Sucuri предлагает очистить ваш сайт WordPress, если он заражается вредоносными программами без каких-либо дополнительных затрат.
В разделе Плагины WordPress лучшие подборки по категориям.
Wordfence – еще один популярный плагин безопасности WordPress. Разработчики предлагают бесплатную версию своего плагина, которая поставляется с мощным сканером для вредоносного ПО. Плагин обнаруживает и оценивает угрозы.
Плагин автоматически сканирует ваш сайт на наличие распространенных угроз, но вы также можете запустить полную проверку в любое время. Вы будете предупреждены, если обнаружены какие-либо признаки нарушения безопасности. Вы также получите инструкции по их устранению.
Wordfence поставляется со встроенным брандмауэром WordPress. Однако этот брандмауэр работает на вашем сервере перед загрузкой WordPress. Это делает его менее эффективным, чем брандмауэр уровня DNS, такой как Sucuri.
iThemes Security – это плагин безопасности WordPress от разработчиков популярного плагина BackupBuddy. Как и все их продукты, iThemes Security предлагает отличный чистый пользовательский интерфейс с множеством опций.
Он поставляется с проверками целостности файлов, усилением безопасности, ограничениями при попытке входа в систему, надежным обеспечением пароля, выявлением ошибок 404, защитой от атак и многое другое.
iThemes Security не включает брандмауэр веб-сайта. Он также не включает собственный сканер вредоносных программ, а использует сканер вредоносного ПО Sitecheck Sucuri.
All In One WP Security является мощным плагином для проверки безопасности, мониторинга и брандмауэра WordPress. Он позволяет легко применять основные рекомендации по безопасности WordPress на вашем веб-сайте.
Плагин включает функции блокировки входа в систему, чтобы предотвратить атаки на ваш сайт, фильтрацию IP-адресов, мониторинг целостности файлов, мониторинг учетных записей пользователей, сканирование подозрительных шаблонов ввода в базы данных и многое другое.
Он также оснащен базовым брандмауэром уровня веб-сайта, который может обнаруживать некоторые распространенные шаблоны и блокировать их. Тем не менее, он не всегда эффективен, и вам придется частенько вручную вводить подозрительные IP-адреса в черный список.
Anti-Malware Security – еще один полезный плагин для защиты от вредоносных программ и безопасности WordPress. Плагин поставляется с активно поддерживаемыми определениями, которые помогают найти наиболее распространенные угрозы.
Плагин позволяет легко сканировать все файлы и папки на вашем сайте WordPress на предмет обнаружения вредоносного кода, бэкдоров, вредоносных программ и других известных шаблонов вредоносных атак.
Плагин требует, чтобы вы создали бесплатную учетную запись на веб-сайте плагина. После этого вы получите доступ к последним определениям, а также некоторые премиальные функции, такие как защита от атак.
Нюанс: пока плагин проводит тщательные тесты, он часто показывает большое количество ложных срабатываний. Согласование каждого из них с исходным файлом – довольно кропотливая работа.
Плагины защиты, антивирусы, ускорение, кеширование тут.
BulletProof Security – не самый красивый плагин безопасности WordPress на рынке, но он по-прежнему полезен благодаря некоторым замечательным функциям. Он поставляется с мастером настройки. Панель настроек также включает ссылки на обширную документацию. Это поможет понять, как работают проверки и настройки безопасности.
Плагин поставляется с программным сканером, который проверяет целостность файлов и папок WordPress. Он включает защиту входа, отключение сеанса ожидания, журналы безопасности и утилиту резервного копирования базы данных. Вы также можете настроить уведомления по электронной почте в журналах безопасности и получать предупреждения, когда пользователь заблокирован.
Читайте также:
