ГлавнаяCmsВзломать сайт cms

Как происходит взлом, и что делать, если сайт взломали? Взломать сайт cms


Могут ли взломать мой сайт, если CMS и скрипты неуязвимы?

Предположим, что на сайте закрыты все уязвимости, пропатчены все бреши и он работает на коммерческой CMS самой последней версии. Могут ли взломать такой сайт?

Ответ – да, могут.

И для этого вовсе не обязательно обладать сверхординарными способностями и иметь в арсенале суперутилиты для взлома. Все гораздо проще, сайт могут взломать не только в результате атак через веб.

Во-первых, взломать хорошо защищенный от веб-атак сайт могут через соседей по аккаунту. Если у веб-мастера несколько сайтов, то с наибольше вероятностью он разместит все сайты на одном аккаунте хостинга. Очень часто сайты на одном аккаунте хостинга не изолированы друг от друга, то есть cкриптами одного сайта можно вносить изменения в файлы другого сайта. И взлом одного сайта может привести к заражению всего shared-хостинга.

Обидно, если на хостинге пять сайтов, четыре из которых – хорошо защищенные интернет-магазины, а пятый - блог на уязвимом WordPress’е или сайт-визитка на Joomla. И именно последний случайно оказывается в поле зрения хакера. Иногда встречаются аккаунты, на которых «царит» настоящий бардак: множество папок со старыми версиями сайтов, тестовые площадки, заброшенные веб-проекты – и все они уютно соседствуют с рабочими веб-лошадками, генерирующими прибыль.

В нашей практике были случаи, когда взломы мультисайтового аккаунта происходили в результате «незасвеченного» нигде– ни в поисковиках, ни в социальных сетях – тестового сайта на техническом домене. Если сайт открывается в браузере и доступен для пользователей, то он доступен и для хакеров.

Сайт могут взломать, перехватив доступы. Предположим, веб-мастер, находясь в кафе или посещая какое-нибудь мероприятие (конференцию, форум, выставку), начинает обновлять на сайте контент. Для подключения он использует WiFi, который раздается организаторами мероприятия. При этом подключение к панели сайта или FTP происходит по незащищенному соединению. Кто находится рядом в этот момент – неизвестно. Доступы от FTP, SSH, хостинга могут быть легко перехвачены программой-сниффером трафика, которая работает у хакера, подключенного к той же сети или через взломанный WI-FI роутер (что сейчас достаточно частое явление).

Есть и другие грустные примеры. В начале марта к нам обратилась владелица сайта, чьи доступы с администраторскими правами к ее веб-проекту были перехвачены в результате заражения компьютера приходящего бухгалтера. История банальна и в тоже время поучительна. Бухгалтер имела доступ к сайту и партнерской базе, хранящейся на нем, поскольку в ее обязанности входило ежемесячное уведомление партнеров об оплатах. В результате взлома компьютера бухгалтера, хакер получил полный доступ к сайту и базе клиентов.

Каким бы неуязвимым ни был ваш сайт, взломать его могут посредством брут-форс атаки – подбора паролей, если ваш пароль слишком простой. Несмотря ни на что многие владельцы сайтов и веб-мастера упорно продолжают игнорировать главное правило создания безопасных паролей – пароли должны быть длинными и сложными, содержать случайную комбинацию цифр, букв и символов, а не комбинации года рождения и имен детей. Зачастую пароли от администраторских аккаунтов представляют собой простую комбинацию клавиш, которую легко запомнить или удобно воспроизвести на клавиатуре. Помните, что если легко вам – легче простого хакерам.

Доступ к сайту злоумышленники могут получить в результате компрометации более высокого уровня - взлома сервера: например, взлом VPS или выделенного сервера. Злоумышленник может получить логин и пароль от базы данных, затем через скрипт phpMyadmin загрузить бэкдор и уже через него выполнить любое необходимое действие с файлами и базой данных (включая “рутование”).

Взлом сервера могут осуществить и через старые компоненты операционной системы (до сих пор сотни серверов работают на уязвимой версии proftpd).

Наконец, получить доступ к хорошо защищенному сайту злоумышленники могут по вине ваших подрядчиков, которые недостаточно аккуратно обращались с вашими логинами-паролями к сайту и хостингу, передавали доступы третьим лицам, работали с зараженных компьютеров и так далее.

Как минимизировать риски взлома, которые происходят не через веб?

Вы автоматически избежите ряда проблем, если будете следовать приведенным ниже рекомендациям:

  1. выберите для размещения своих сайтов надежного хостера. Не хватает опыта и знаний по данному вопросу? – Выбирайте хостинг-провайдера из ТОП-10 РФ и СНГ. Не «ведитесь» на дешевые тарифы «доморощенных» хостеров. По сути, последние – даже не поставщики хостинговых услуг, а всего лишь реселлеры, которые арендовали или купили серверные площадки по более низкой «оптовой» цене, а продавать будут «в розницу» по более высокой. Надлежащей заботы и сервиса от таких горе-хостеров не ждите.
  2. Если на аккаунте хостинга находится несколько сайтов, позаботьтесь о том, чтобы все сайты были хорошо защищены. Важные для вас веб-проекты часто взламывают через забытые и давно ненужные интернет-ресурсы, соседствующие с ними на одном аккаунте. Не нужен сайт? Не планируете инвестировать в его безопасность? – Заблокируйте на время. Поддерживайте порядок на своем аккаунте. Беспорядок на хостинге – путь к беде.
  3. Закройте админ панель сайта дополнительным средством защиты – например, ограничением по IP, серверной аутентификацией или каким-то другим элементом двухфакторной защиты – например, через SMS. Таким образом вы сможете противостоять брут-форс атакам.
  4. Регулярно меняйте пароли. Частая смена паролей минимизирует риски несанкционированного проникновения на сайт злоумышленников (даже если в какой-то момент они смогли перехватить доступы).
  5. При работе в открытых WiFi сетях используйте защищенное подключение. Приобретите VPN аккаунт и используйте его при работе в публичных сетях.
  6. Работайте по безопасному протоколу SFTP, SFTPS, SSH вместо небезопасного
  7. Проводите инструктаж подрядчиков по безопасной работе с вашим сайтом, прежде чем предоставить доступы от сайта и хостинга. А после завершения работ поменяйте все пароли, удалите пользователей, которых создавали специально для выполнения задач, и проверьте сайт на предмет стороннего кода сканером вредоносного кода AI-BOLIT и веб-сканером ReScan.pro.

 

Обсуждаем и комментируем

revisium.com

Как взламывают большинство сайтов. Примеры нецелевого взлома.

Мы неоднократно писали о том, что количество сайтов, подвергающихся обезличенным (нецелевым) атакам, в разы превышает количество жертв атак целевых. По нашей статистике, только каждый четвертый сайт злоумышленники взламывают целенаправленно, остальные сайты, поступающие к нам на лечение и защиту, - результат массового взлома и заражения.

Пострадать в результате нецелевой атаки довольно просто: для этого достаточно, не заметить или проигнорировать критическую уязвимость в CMS, шаблонах или плагинах своего сайта. Любая незакрытая брешь – отличный шанс очутиться среди себе подобных «товарищей по несчастью» и прочно закрепиться в хакерской выборке кандидатов для взлома. А в случае «успешной» атаки приготовьтесь к тому, что ваш сайт начнут активно использовать для спам-рассылки, заражения пользователей, хостинга фишинговых страниц, атак на другие сайты или заработка на рекламе. 

Найти сайты (их тысячи) со схожими слабыми параметрами для хакера не составляет большого труда. Информацию об уязвимых сайтах всегда можно пробить по Google Hacking Database (GHD) – базе данных «дорков» - поисковых запросов на мета-языке Google, позволяющих найти сайты, уязвимые к тем или иным атакам по определенным сходными свойствами. Например, хакеры могут найти все проиндексированные в поисковой системе сайты с установленным уязвимым плагином или сайты, которые раскрывают содержимое каталогов, т.е. позволяют просматривать и загружать из них файлы (с паролями, настройками и т.п.)

Если на вашем сайте есть слабое звено и веб-проект уязвим к определенному виду атак, то рано или поздно вас взломают. Это нужно понимать каждому веб-мастеру и владельцу сайта.

Последние, обычно, не верят, что найти и взломать уязвимый сайт можно буквально за пару минут, не имея под рукой никаких специализированных хакерских инструментов. Поэтому в качестве иллюстрации мы приведем простой пример, как, используя возможности Google, злоумышленники находят и взламывают веб-проекты, владельцы которых своевременно не позаботились об их защите или допустили ошибки при настройке хостинга.

В качестве примера рассмотрим “дорк”, который появился в базе Google Hacking Database от 1 сентября 2015 года. Он позволяет найти сайты с открытыми каталогами (в таких каталогах можно не только увидеть листинг служебных файлов, но и просмотреть их содержимое, например, найти пароли).

Отправляем этот запрос в поисковую систему Google и видим список сайтов с открытыми листингами каталогов - это потенциальные жертвы хакера. Выбираем среди найденных сайтов случайный, например, последний в списке.

Кликаем по ссылке - открывается список каталогов, по ним можно «погулять» как в проводнике, и в результате серфинга можно заметить файл serverconfig.xml, который в открытом доступе хранит логины и пароли от базы данных. Учитывая то, что иногда учетные записи совпадают с FTP или SSH, таким образом хакер может получить несанкционированный доступ не только к базе данных, но и всему серверу.

На весь вышеописанный процесс ушло порядка двух минут, у хакера же в «боевых условиях», использующего автоматизированные решения, это занимает еще меньше времени, а счет скомпрометированных ресурсов обычно идет на тысячи.

Обидно оказаться в числе тех, кто превратился в легкую добычу в руках хакера, хотя такой ситуации легко избежать. Думайте о защите своих веб-проектов заранее. Если ваш сайт будет чуть более защищен, чем среднестатистический (с CMS “из коробки” и настройками по-умолчанию), то проблема нецелевого взлома вас обойдет стороной. 

Обсуждаем и комментируем

revisium.com

Как взломать сайт. Виды взлома и защита от них.

Как взломать сайт. Виды взлома и защита от них.

Хотите узнать, как взломать сайт? Или же наоборот, узнать, как можно защититься от взлома? Каждый день происходит взлом сайтов, которые удаляются или мошенники требуют выкуп. Как говорится, последний смеется тот, кто делает BackUp.

Некоторые виды атак не дадут вам доступ к административной панели или хостингу, но они могут существенно навредить сайту.

Не смотря на то, что создать сайт стало намного проще, чем это было десять лет назад, всё равно далеко не каждый разработчик знает, как защитить свой сайт. Существует много способов взломать сайт, давайте же разберемся, какие они, и как защитить сайт от взлома.

Методы взлома сайта:

Это не все методы взлома сайта, однако именно они являются самыми распространенными. Никогда не стоит пренебрегать защитой своего сайта. Особенно стоит об этом задуматься, если у вас крупный проект, который рано или поздно будет подвержен атаке. Дочитайте до конца и узнайте, как взломать сайт или защитить свой проект от атак.

Как взломать сайт – методы и защита от них!

Первый вид атаки, DDOS, он не даст вам доступа к управлению сайтом, однако есть возможность обвалить сайт, что может принести много вреда. Если у вас сайт с большим трафиком, то вам конечно же не хочется потерять несколько дней в пустую. А то и позиции в поисковых системах.

 DDOS  – распределённая атака типа «отказ в обслуживании». Сетевой ресурс выходит из строя в результате множества запросов к нему, отправленных из разных точек. Обычно атака организуется при помощи бот-нетов.

Длительность отказа сайта зависит от длительности атаки и от вашей подготовки к такому виду защиты. Как правило, хостинг предоставляет защиту от DDOS, однако это не значит, что вы можете расслабиться. Данная защита может защитить от нескольких тысяч запросов, которые посылают на ваш сайт бот-неты, а если их будет больше?

Лучших способ защиты – подключение CloudFlair. Они дают возможность бесплатно пользоваться ресурсом, ускоряют загрузку сайта, а также кэшируют страницы. Делается всё за пару минут и не требует материальных вложений.

 SQL Injection  – этот вид атаки уже устарел и его редко где можно встретить. Суть заключается в том, что в формы обратной связи посылается запрос, который никак не обрабатывается и выдает нужную информацию. Например, в блок комментариев написать запрос drop table users, таблица пользователей будет очищена.

Защита от данного вида взлома проста, это использовать подготовленные запросы. Они не изменяются никак, а только берут аргументы. PDO можно использовать во многих языках, никогда не используйте аргумент SET NAMES, используйте кодировку в DSN строке(первый аргумент PDO). Также стоит ограничивать доступ пользователей к БД. Также всегда стоит делать резервное копирование базы данных, чтобы не попасть в неприятную ситуацию.

 XSS(CSS)  – (Cross-Site Scripting) – данный вид атаки всё также осуществляется через user input. Целью данной атаки являются пользователи, а не базы данных. Как правило используют javascript или iFrame. C помощью данного вида атаки можно перехватить cookie пользователя и зайти на его аккаунт без знания пароля и логина. Особенно опасной эта уязвимость является для коммерческих сайтов или интернет-атак. Взломать сайт без защиты от XSS очень легко, через те же комментарии.

Защита от XSS атак может быть разной, например фильтрация вывода из user input. Легче всего будет поставить Twig или Blade, защита от данного вида атак там грамотно реализована из “коробки”.

 CSRF  – (Cross-Site Request Forgery) – достаточно вредная атака, которая может навредить людям. Создается frame и на атакованном сайте по клику в любой области будет происходить действие, которое может навредить пользователям. Например может быть отправлено сообщение от вашего имени какому-то знакомому с просьбой переслать денег.

Защититься от CSRF очень просто, достаточно добавить CSRF токен для формы в нужном вам месте. Он сохраняется на момент сессии.

 MITM  – (Man-In-The-Middle) – очень распространенный вид атаки, о котором слышал уже наверное каждый. Суть атаки заключается в том, что человек по середине, он же и выступает в роли хакера, перехватывает ваши пакеты и подменяет их. Например, вы отправляете одно сообщение вашему другу, а оно приходит уже другое. Как взломать сайт с помощью MITM? Очень просто, а значит и защититься очень просто! Достаточно добавить на ваш сайт SSL или TLS с принудительной загрузкой сайта с защищенным протоколом. Если сайт может быть загружен с протоколом HTTP значит взломать его с помощью MITM реально.

 Clickjacking  – С помощью фрейма, который абсолютно прозрачен перенаправляют пользователей на сторонние ресурсы. Таким образом люди его не видят, создается кнопка, которая привязана к курсору и при любом клике на сайте будет происходить заданное хакером действие. Вариантов защиты от данной атаки взлома сайта много, однако самая эффективная – использовать noscript>.

 Brute Force  – перебор паролей с заданным логином или почтой. Как правило перебор не слепой, используются слитые базы паролей. Защититься можно легко, поставить каптчу или поставить лимит на количество неверных попыток входа.

 ZeroDay  – уязвимость нулевого дня. Заключается она в том, что после релиза была допущена ошибка и с помощью нее можно взломать сайт. Для того, чтобы с вами такого не произошло всегда обновляйте используемые технологии.

 Backdoor  – на сайт внедряются зашифрованные скрипты, которые по отдельности дают доступ к ресурсу и как правило они себя копируют, чтобы было сложнее избавиться от них. Проверяйте код на такие скрипты, не устанавливайте сторонние плагины, которые не прошли проверку и всё будет хорошо.

 Uploads  – взломать сайт с помощью загрузки файлов можно, если нет проверки на форматы и содержимое. Таким образом можно загрузить скрипт в аватарку и запустить его на сайте по ссылке аватарки. Требуется ставить лимит на файлы, а также менять размер фотографий, минимально, однако это уже не даст возможности обмениваться злоумышленникам зашифрованным с помощью стеганографии текстом.

Подписывайтесь на обновления сайта, а также на наш Telegram. Также вы можете поддержать нас, просто поделившись статьей в социальных сетях.

Поделиться ссылкой:

Похожие записи

www.make-info.com

Защита сайтов от взлома — Пошагово

Интерфейс PHPSECURE достаточно логичен и очень просто, если хоть немного разобраться с принципами его работы. Однако не все хотят разбираться.

Специально для тех, кому чуждо всё техническое, было решено создать раздел с пошаговыми руководствами по эффективной защите сайтов, работающих на платформе популярных CMS.

В целом, действия необходимые для защиты сайта под управлением той или иной CMS почти идентичны, но в мелочах всё же есть различия.

Если Вашей CMS нет в списке пошаговых руководств - воспользуйтесь общей инструкцией:

Итак, для защиты Вашего сайта, Вам необходимо выполнить несколько простых шагов.

1. Первым делом, скачайте и установите PHPSECURE. Установка выполняется в три клика и не представляет сложностей - просто загрузите скрипт на сервер и откройте его в браузере, после чего, следуйте инструкциям системы.

2. После того, как Вы установили PHPSECURE, добавьте URL-адрес админ.панели PHPSECURE в закладки браузера, поскольку других ссылок на админку у Вас нет, а адрес несложно забыть.

3. Теперь, войдите в админ-панель PHPSECURE. Нажмите на значек WWW в верхнем-правом углу страницы, что бы открыть свой сайт в новом окне. Пройдите по нескольким страницам сайта и админки сайта (если он работает на CMS имеющей админку).

4. Теперь, в панели PHPSECURE, перейдите в раздел "Предотвращение запуска" и перенесите все файлы из списка новых, в список разрешенных.

5. Далее, необходимо убедиться, что у Вас на сайте уже не завелась какая-либо зараза. Для этого перейдите в раздел "Сканер", выберите корневую директорию сайта и выполните сканирование. Сканер не должен обнаружить угрозы с рейтингом выше 25. Если же такие нашлись - у Вас не все в порядке и следует внимательно проверить найденные файлы.

6. После того, как выполнено сканирование и устранены найденные угрозы (при их наличии), осталось защитить сайт от SQL-инъекций, а также затруднить доступ к файлу конфигурации. Для этого, Вам нужно открыть в любом редакторе файл, в котором содержатся логин и пароль к БД MySQL Вашего сайта, такие файлы, обычно называются config.php, configuration.php, dbconfig.php, dbconf.php, wp-config.php и т.п.

7. Открыв такой файл, найдите в нем параметры доступа к MySQL (хост, логин, пароль и имя БД) и перейдите в панели PHPSECURE в раздел "Фильтрация запросов". В правой части страницы, введите параметры MySQL и нажмите на кнопку "Получить имена таблиц". Полученные имена, добавьте в список простых фильтров, нажав на стрелку влево "<". Ниже, в списке простых фильтров, введите имя файла, в котором хранятся параметры доступа к MySQL (из которого Вы брали эти параметры). Теперь, внизу страницы, нажмите на кнопку "Сохранить настройки". Все - выполнение SQL-инъекций и доступ к файлу конфигурации будут значительно затрудены, после того, как Вы активируете защиту.

8. Осталось активировать защиту. Для этого перейдите в раздел "Конфигурация" и включите режим предотвращения запуска, а так же фильтрацию запросов. Теперь Ваш сайт под защитой.

Примечание: Если, при открытии какой-то страницы Вашего сайта, Вы видите надпись "PHPSECURE Hacking denied" (или надпись, которую Вы самостоятельно указали в настройках) - значит эта страница открывается скриптом, запуск которого небыл разрешен. Достаточно просто зайти в панель PHPSECURE, в раздел "Предотвращение запуска" и перенести этот скрипт из списка новых/измененных в список разрешенных.

Примечание: Если какой-то скрипт регулярно оказывается в списке измененных - значит его содержимое меняется динамически. Такой скрипт необходимо перенести в список игнорируемых.

Пусть будет меньше взломов, меньше вирусов, меньше спама! Расскажите всем!

phpsecure.ru

Где и что искать после взлома сайта Сайт Кузеванова Александра

Если сайт взломан, мало удалить с него вирус и загруженный PHP Shell. Нужно еще найти причину, по которой произошел взлом, иначе через день-два на сайте снова будет под бодрую музыку развеваться красивый турецкий иностранный флаг. Чаще всего причина — украденный пароль от FTP, устаревшая версия CMS или плагина к ней, но как найти, что именно было использовано для проникновения?

Имея некоторый опыт в этой сфере (в среднем наша техподдержка занимается поиском причины взлома сайта раз в неделю), мы систематизировали накопившуюся информацию.

Итак, зачем вообще взламывают сайты? И что делать, если сайт взломан, как найти причину и защититься от последующих атак?

Зачем взламывают сайты

Процесс взлома сайтов сейчас поставлен на поток. Ботнеты используют известные эксплойты к распространенным CMS, взламывают сайты, устанавливают на них свои скрипты и дальше могут использовать взломанный сайт в любых целях. Вирусы крадут пароли от FTP, подключаются к сайтам и заражают их вирусами, которые в свою очередь заражают посетителей сайтов, после чего круг повторяется. Чаще всего после взлома сайта происходит следующее:Дефейс сайта. Это можно назвать, скорее, озорством, дальше дефейса дело часто не идет.Заражение страниц сайта вирусом. Вирусы могут как просто добавляться в конец каждой страницы сайта, так и быть довольно изощренными. Например, нам встречался вирус, заражавший конкретный класс Joomla, отвечающий за вывод данных в браузер.Поиск других сайтов в соседних папках и их заражение.Рассылка спама.Загрузка PHP Shell и выполнение произвольных действий — например, попытка взлома сервера с помощью существующих эксплойтов к операционным системам.Установка ботов, которые подключаются к серверу IRC и могут выполнять произвольные команды «хозяина» — например, производить DDoS других сайтов.То есть, действия взломщиков направлены на дальнейшее распространение ботов, создание сети (ботнета) и дальнейшее ее использование в своих целях.

Алгоритм поиска причины взлома

Алгоритм сам по себе очень простой:Найти следы взлома.Определить точное время взлома.По логам найти, как именно поломали сайт.Сложность составляет реализация пунктов 1 и 3. На них мы остановимся подробнее.

Как искать следы взлома

При взломе практически всегда остаются следы: файлы, которые злоумышленник использовал для работы, например, PHP Shell. Классический способ взлома CMS:Через какую-либо уязвимость загрузить PHP Shell (или получить через уязвимость доступ администратора CMS и загрузить PHP Shell через менеджер файлов).Через PHP Shell сделать все остальное.Поэтому в первую очередь необходимо искать такие файлы — файлы, очевидно не принадлежащие сайту. Как правило, загруженные скрипты называются довольно необычно и сильно выделяются среди собственных скриптов CMS:

wzxp.phpgwd.phpa10881d.php.2046Результат работы эксплойта, запущенного для взлома сервера, может выглядеть так:./w.sh./env./env.c./program.c./program.o./w00t.so.1.0/tmp/sh/tmp/sh3

Эти файлы могут быть расположены как в корне сайта, так и в папке tmp/ или cache/. Поискать их стоит также в папках вроде images/, upload/, user_files/ и т. д. — часто через уязвимости в редакторах или библиотеках фотографий скрипты загружаются именно в то место, куда обычно загружаются фотографии или хранятся временные файлы.

Помимо файлов сайта стоит также проверить общий /tmp сервера — в нем могут находиться временные файлы, использованные для взлома или для запуска ботов.

Обязательно загляните в файл .htaccess — в нем могут быть добавлены перенаправления на другие сайты, распространяющие вирус. При этом файл .htaccess может быть размещен как в корне сайта, так и выше, поэтому не поленитесь посмотреть все директории вашего аккаунта.

Иными словами, необходимо искать все необычное/непонятное и заглядывать внутрь всех подозрительных файлов. PHP Shell может выглядеть, например, так:

$auth_pass = «»; //75b43eac8d215582f6bcab4532eb854e$color = «#00FF66»; //Colour$default_action = «FilesMan»;$default_charset = «Windows-1251»;preg_replace(«/.*/e»,»\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28’7b1tVxs50jD8OXvO9R9Er3fanhhjm2Q2Y7ADIZCQSSAD5GUC3N623bZ7aLs93W0Mk+W/31Wll5b6xZhkdq/7OedhJtDdKpVKUkkqlapK3rDM1tzJLL4tl7qn+ycf90/// … много кода в base64

Ключевые моменты, на которые стоит обращать внимание в скриптах PHP:Co0lHaZZkeR’ский стиль написания текста.Наличие слов Exploit и Shell.Наличие большого количества кода в base64.Наличие eval() или функции preg_replace() с ключом /e в первом аргументе.В конце концов, можно просто зайти браузером и посмотреть, что делает этот скрипт.

Файлы можно искать и вручную, но быстрее, если взлом произошел недавно, воспользоваться командой find:

# find ./public_html -mtime -3d# find ./public_html -mtime -10h

(синтаксис find указан для FreeBSD). Эти команды покажут файлы, изменявшиеся за последние три дня и последние 10 часов, соответственно.

Если ничего не помогает, можно просто поискать все файлы, содержащие закодированное в base64 содержимое, например, так:

# find ./ -name ‘*.php’ | xargs grep -E ‘[0-9a-zA-Z/]{80}’

Эта команда найдет все скрипты PHP, в которых есть строки, похожие на base64 длиной не менее 80 символов.

Определение времени взлома

Когда файлы найдены, определить время взлома очень просто — достаточно посмотреть время изменения самого раннего файла.

Если подозрительных файлов не найдено, но сайт заражен вирусом, посмотрите дату изменения файлов index.php, index.html или тех, в которых обнаружите вирус. Скорее всего в этом случае сайт взломали, украв пароль от FTP.

Поиск журналов взлома сайта

Теперь самое главное — чтобы эти журналы были в наличии!

Если на сайте только произведен дефейс или добавлен вирус ко всем файлам index.html, скорее всего, сайт взломали через кражу пароля FTP (или, гораздо реже, SSH). Посмотрите журналы подключения по FTP и SSH во время взлома — присутствие в нем неизвестных IP-адресов или большого количества разных IP-адресов, осуществивших успешное подключение к сайту, означает, что пароль украден.

В этом случае достаточно проверить компьютеры, с которых осуществлялся доступ к сайту, на вирусы, сменить пароли FTP и никогда больше не сохранять пароли в клиентах FTP.

Если же на сайте присутствуют PHP Shell или вредоносные скрипты (например, для рассылки спама), скорее всего, сайт взломали через уязвимость в CMS или каком-либо её плагине. В этом случае потребуется проанализировать логи веб-сервера.

Чтобы лучше понять, что необходимо искать, рассмотрим, как происходит взлом CMS.Злоумышленник определяет, что на сайте установлены CMS или ее плагины, либо другое ПО (устаревшая Joomla, phpMyAdmin, редактор WYSIWYG, галерея фотографий и т. д.), потенциально подверженные уязвимости.Он начинает перебирать известные эксплойты к этому ПО. Цель — каким-либо образом загрузить свой файл на сайт.Когда уязвимость найдена, взломщик загружает PHP Shell.Подключившись к PHP Shell, взломщик получает полный доступ к сайту и дальше может использовать его в любых целях.Важный момент — загрузка PHP Shell. В предыдущей части мы определили, в какое время на сайт были загружены вредоносные скрипты. Теперь достаточно найти обращения к ним в журнале веб-сервера. Таким образом мы сможем определить IP-адрес злоумышленника. Это можно сделать простым grep’ом в access.log по имени файла PHP Shell’а.

Если удалось определить IP-адрес

Определив IP-адрес взломщика, мы производим поиск этого IP-адреса по журналу веб-сервера и видим все действия, которые он совершал. Где-то близко к моменту обращения к PHP Shell будет успешное использование уязвимости сайта.

Если определить IP-адрес не удалось

Описанный выше способ работает, если известно конкретное имя файла, через которое производилась работа с сайтом после взлома. Однако это имя не всегда известно. В этом случае придется поискать момент взлома немного подольше, но найти его все равно можно.

Большинству, подавляющему большинству взломов свойственны запросы HTTP POST, так как через них происходит загрузка файлов на взламываемый сайт. Через POST злоумышленник может также пытаться взломать форму ввода пароля или просто зайти в раздел администрирования с украденным паролем.

Если известно время взлома сайта (а мы его уже знаем), необходимо поискать в журнале веб-сервера все запросы POST, находящиеся близко ко времени взлома. Здесь нет конкретных советов — выглядеть они могут совершенно по-разному, но выглядеть они будут в любом случае необычно. Например, это могут быть запросы, содержащие ‘../../../../’ или длинные запросы, содержащие имена файлов или запросы SQL.

Если ничего не удалось найти

Такое тоже может быть. В этом случае можно порекомендовать только чистую переустановку CMS и ее расширений и последующий импорт данных. Обязательно убедитесь, что версия CMS и ее расширений — последняя.

И ее расширений! Чаще всего взломы производятся не через ядро системы управления сайтом, а через какой-нибудь устаревший плагин, автор которого давно забросил его разработку.

Ну и, разумеется, смените все пароли, которые имеют какое-либо отношение к сайту.

Хозяйке на заметку 😉

В процессе поиска уязвимостей на сайте, если нет возможности заблокировать к нему доступ посетителей, заблокируйте хотя бы запросы POST. Это предотвратит возможность применения большинства стандартных эксплойтов.Не используйте устаревшие версии CMS и плагинов к ним. Следите за обновлениями!После определения причины взлома не ограничивайтесь удалением найденных скриптов — добавленные злоумышленником точки проникновения могут быть хорошо спрятаны. Лучшая схема восстановления сайта после взлома — это закрыть к нему доступ посетителей, найти причину взлома, восстановить сайт из резервной копии (этим мы исключаем любые изменения сайта, которые мог произвести злоумышленник), обновить CMS, убедившись, что уязвимый компонент также обновился, после чего снова открыть доступ к сайту.

kuzevanov.ru

Почему взламывают даже защищённые CMS на безопасном хостинге

Очевидно, что если у сайта есть уязвимости, то его можно взломать с помощью веб-атак. Но даже если сайт защищен техническими средствами, работает на надежной CMS, его все равно могут скомпрометировать. Каким образом это происходит и как защищать сайт от различных вариантов взлома не через веб-уязвимости — oб этом рассказал на партнёрской конференции «1С-Битрикс» Григорий Земсков, руководитель компании «Ревизиум».С каждым годом растет число взломов и пострадавших от них владельцев сайтов. А в последние два года проблема безопасности сайтов становится особенно актуальной: в разы возросло число атак и объемы входящего опасного трафика, и, как следствие, количество взломанных ресурсов. Видя это, веб-мастеры и владельцы веб-проектов постепенно начинают осознавать проблему и интересоваться вопросами информационной безопасности сайтов, в частности, их защитой. Для того, чтобы грамотно защитить свой ресурс, владелец веб-ресурса должен понимать, какие есть варианты взлома, как действует злоумышленник, какие векторы атак наиболее критичны и как их закрыть.

К сожалению, существует очень много статей и видео, которые вводят в заблуждение интересующихся этими вопросами. Проблема здесь в том, что вопрос безопасности освещается однобоко, обычно рассматриваются только технические средства защиты. Причем не в полном объеме, а только те, которые блокируют веб-атаки. Это дает веб-мастерам чувство ложной защищенности и абсолютно не гарантирует бесперебойную работу веб-ресурса и защиту от несанкционированных изменений. В большинстве случаев у владельца сайта нет желания тратить свои ресурсы: деньги, время на безопасность проекта, поэтому выбирается на его взгляд оптимальная стратегия: использовать популярную коммерческую систему управления сайтом и разместить сайт на популярном хостинге. Все, вроде бы, логично: защищенная система работает в защищенной среде, то есть можно более не думать про безопасность и защиту. Но это всего лишь одно из популярных заблуждений про безопасность сайтов, наряду с тем, что достаточно одних лишь технических мер защиты.

Увы, все эти «мифы» — про использование лишь веб-атак для взлома сайтов, про защищенность CMS и достаточность технических мер, приводят к новым массовым взломам сайтов. Что же делать, чтобы этого не происходило? Необходим комплексный подход к вопросу безопасности сайта. Далее мы рассмотрим, почему нужно уделять постоянное и пристальное внимание как техническим средствам защиты, так и организационным мерам. Это важно хотя бы потому, что существует много вариантов взлома сайтов, которые выполняются нетехническими методами и без использования веб-уязвимостей.

Варианты взлома сайтов

Все варианты взлома сайтов можно условно разделить на три большие группы (выделены жёлтым, голубым и серым цветом):

Больше всего говорят и пишут про взломы посредством веб-атак. Поскольку данный аспект освещен достаточно хорошо, в этой публикации я лишь вскользь упомяну о нем, а основной акцент хотелось бы сделать на двух незаслуженно забытых категориях: компрометации ресурсов техническими средствами без использования «человеческого фактора» (желтый блок) и взлом по вине подрядчиков и сотрудников, то есть тех, кто помогает обслуживать сайт. В количественном выражении взломы через веб составляют около 75%, чем и обусловлено столь пристальное внимание к этому классу.

Что касается остальных двух, то они не такие популярные, но все же не менее важные. По нашей статистике, на взлом по вине подрядчиков и сотрудников приходится около 5% инцидентов. Но эта цифра постепенно растет, поскольку в настоящий момент много сайтов отдается на обслуживание в веб-студии, диджитал-агентства или фрилансерам.

Итак, рассмотрим варианты по-порядку. Начнем с самой многочисленной группы, взлом сайта посредством веб-атак:

Защита от веб-атак

Избавиться от веб-атак нельзя, но им можно противодействовать. Ниже представлен список мер против взлома через веб.

  1. Необходимо обновлять CMS и скрипты. С каждой новой версией выходят патчи безопасности: закрываются уязвимости, исправляются ошибки. Всё это позволяет снизить вероятность взлома через веб, хотя и не защищает от него на 100%, потому что и в новых апдейтах, к сожалению, могут появиться новые «дыры».
  2. Необходимо минимизировать объем плагинов в CMS. Чем больше плагинов, тем больше вероятность наличия уязвимостей. В идеале, использовать решение «из коробки», с примененными патчами и критическими обновлениями, которые закрывают все известные публичные уязвимости в ядре CMS. Но, поскольку, функциональности не всегда хватает, то перед установкой плагинов нужно обязательно проверять, насколько они защищены и безопасны.
  3. Доработки нужно отдавать опытным веб-разработчикам, которые имеют представление о безопасности сайтов и источниках проблем, то есть понимают необходимость фильтрации входных и выходных параметров, безопасных алгоритмов аутентификации и авторизации, безопасного хранения данных и т.п.
  4. Трафик необходимо фильтровать. По статистике сервисов проксирования трафика, около 50% всех запросов идут от ботов, причем примерно четверть тех запросов – это атаки на веб-ресурс. Фильтрация запросов к сайту блокирует атаки, паразитный трафик и снижает нагрузку при DDOS- и брутфорс-атаках. Фильтровать можно как с помощью внешнего сервиса (Web Application Firewall/AntiDDOS), так и модуля веб-сервера (naxsi/mod_security). Еще одна полезная функция WAF – это виртуальный патчинг уязвимостей. Необязательно (да и не всегда возможно) ставить «заплатки» на скрипты, но WAF может выполнять виртуальный патчинг, то есть на лету блокировать опасные запросы, не давая эксплуатировать уязвимость. Кроме сервиса и модуля веб-сервера, файрвол бывает встроен в CMS. Он, конечно, не может быть полноценной заменой внешних сервисов WAF или AntiDDOS, но частично снижает вероятность взлома в результате веб-атак.
  5. Необходимо использовать плагины и сервисы для защиты от брутфорса. Скажем, установленный на VPS Fail2ban через несколько неудачных попыток авторизации на некоторое время блокирует клиента. Это существенно затрудняет и растягивает во времени подбор пароля.

Некоторые веб-мастера уже применяют перечисленные технические средства и меры защиты, и потому считают свои сайты неуязвимыми. Но, увы, сайт все равно могут взломать и завирусовать.

Если CMS неуязвима

Почему взламывают даже неуязвимые CMS на безопасном хостинге? Причина кроется в том, что существуют и другие варианты компрометации или заражения сайтов, совсем не обязательно, что сайт взломают через уязвимости в скриптах. Приведу несколько из них:

Подытожу способы взлома не через веб:

  1. Перехват или кража доступов, то есть компрометация доступов к сайту.
  2. Брутфорс-атака на сервисы: SFTP, FTP, SSH или административную панель хостинга.
  3. Взлом сайтов через «соседей».
  4. Компрометация сервера хостинга, то есть получение несанкционированного доступа через уязвимости или ошибки настройки.

Защита от взлома

Как от этого защищаться?

  1. Нужно правильно подбирать хостера, обращать внимание на используемые технические средства и сервисы, на наличие изоляции сайтов внутри аккаунтов. Всё это значительно снижает вероятность взлома.
  2. Размещайте сайты изолированно. Не экономьте на безопасности, не ленитесь создавать для сайтов отдельные аккаунты. В идеале нужно размещать каждый сайт на отдельном аккаунте. Если это сервер, также создавайте для каждого сайта отдельный пользовательский аккаунт. Сейчас даже можно найти хостинг-компанию, у которой сайты размещаются изолированно внутри shared-аккаунта. Таких не много, но они есть.
  3. Используйте ограничение по IP или двухфакторную аутентификацию при входе в панель управления, при работе с FTP и SSH. Нужно обязательно устанавливать дополнительную защиту, то есть ограничивать доступ только для доверенного круга лиц.
  4. Регулярно меняйте пароли. Очевидный совет, которому следуют единицы. Это защищает во многих случаях, даже при компрометации доступов. Если злоумышленник не успел ими воспользоваться, то регулярная смена паролей позволяет сохранить свой доступ к сайтам. Дело в том, что вы не знаете, был ли факт компрометации и исходить нужно из пессимистичного сценария. Поэтому в качестве превентивной меры необходимо регулярно устанавливать новые пароли.

    Кроме того, важно не просто их менять, а иметь некую разработанную политику безопасности, определяющую процедуру смены паролей с точки зрения частоты и стойкости. Это должен быть спланированный и поддерживаемый процесс.

  5. При работе с сайтом по FTP/в админке используйте VPN для предотвращения перехвата доступов, чувствительных и конфиденциальных данных.
  6. Забудьте про FTP и заблокируйте его на хостинге, так как он небезопасен. Если на аккаунте есть такая возможность, подключите SFTP — это надстройка над SSH-протоколом для работы с файлами. В настоящий момент он поддерживается практически на всех хостингах. С точки зрения работы с файлами, разницы с FTP вы не заметите, а с точки зрения безопасности – разница колоссальная.
  7. Если вы очень часто пользуетесь какими-то функциями в панели управления, то создайте отдельный аккаунт с ограниченной функциональностью и вынесите эти популярные функции в этот аккаунт. Если у вас его и взломают, то получат только ограниченный доступ к управлению сайтами.

Когда виноват подрядчик или сотрудник

Порой «уязвимостью», через которую взламывают и заражают сайт, является сам человек. В частности – сотрудники и подрядчики, обслуживающие сайт: контент-менеджеры, SEO-специалисты, веб-разработчики. Какие проблемы безопасности подстерегают владельца сайта в этом случае?

  1. Недобросовестный подрядчик. Часто бывают ситуации, когда сайты отдаются на обслуживание фрилансерам, которые не всегда добросовестны. Например, есть вероятность, что в результате сотрудничества ему что-то не понравится, покажется мало денег, он обидится на критику и начнет шантажировать владельца сайта доступами. Или он просто использует свои полномочия администратора и повредит сайт. Поскольку у подрядчика есть полный контроль над сайтом, он может внедрить на страницы вредоносный код, может начать продавать на нем ссылки с биржи Sape.ru/Trustlink/и пр., размещать несанкционированную рекламу. И порой владелец сайта или менеджер проекта не догадываются, что бывший веб-мастер «паразитирует» на веб-ресурсе, оставив на нем свои «закладки».
  2. Бывает, что подрядчик устанавливает плагины, которые содержат уязвимости или бэкдоры. Например, владелец сайта находит красивый плагин галереи для сайта и просит фрилансера купить и настроить этот модуль. Фрилансер находит такой же плагин на «варезном» сайте, берет деньги с заказчика на покупку, но на самом деле скачивает бесплатно. В «нулленом» варианте будет присутствовать некая «полезная» нагрузка в виде бэкдора или «черных» seo-ссылок. Владелец сайта об этом скорее всего никогда не узнает, потому что не будет проверять то, что установил фрилансер.
  3. Утечка доступов — тоже очень серьезный момент, потому что часто подрядчики не задумываются о безопасности клиентских доступов и сайтов, и небрежно ими распоряжаются. Например, крупное диджитал-агентство обычно работает по различным задачам с партнерами (субподрядчиками), которым передаются клиентские доступы, и что с ними делают партнеры, никто не знает. Эти доступы могут передаваться открыто через мессенджеры по небезопасному сетевому подключению, сохраняться в текстовых файлах, храниться в различных незащищенных CRM и т.п. В итоге шансов раскрытия данных доступов масса, и достаточно сложно будет найти причину компрометации.

    Самый живой пример — это когда такой партнер крупного диджитал-агентства сидит в кафе, обновляет сайт по FTP, а где-нибудь рядом с ним устроился хакер, который перехватывает трафик в той же WIFI сети. Или роутер, через который работает специалист в коворкинг-кафе, заражен трояном. Вредоносное ПО собирает все эти доступы и передает злоумышленникам. Сейчас подобное уже не редкость, перехват траффика в открытых сетях – операция очень простая и эффективная. Поэтому работать в публичном месте без активного VPN – это почти преступление.

  4. И последний вариант — использование социальной инженерии. Скажем, подрядчику, приходит фишинговое письмо: «Ваш сайт взломали! Пожалуйста, срочно смените пароль!» и ссылка. Напуганный исполнитель в замешательстве кликает по ссылке, ему открывается знакомая форма авторизации CMS, но он не замечает, что страница загружена с подставного сайта злоумышленника. Вводит пароль и последний благополучно отсылается хакеру.

Что делать? Как защититься? Для защиты от подобных инцидентов и проблем владелец сайта наряду с техническими средствами должен внедрять и организационные меры защиты.

  1. Управлять доступами. Владелец должен знать, когда и как их менять, у кого они есть, кому их передавать и в каком объеме. Это защитит от многих проблем.
  2. Проводить аудит безопасности после выполнения работ подрядчиком. Файлы, базу и страницы сайта можно проверить самостоятельно с помощью доступных сканеров или инструментов для контроля целостности, а можно обратиться к соответствующим специалистам по безопасности.
  3. Инструктировать подрядчиков. Обязательно нужно составить руководство по безопасной работе с сайтом для сотрудников и подрядчиков и проинструктировать по нему. Многие специалисты могут отлично выполнять свои задачи, но не задумываться о безопасности сайта.
  4. Работать по договору и с проверенными компаниями. Сотрудничество с фрилансерами часто оборачивается проблемами безопасности с сайтом.

В заключение

Безопасность – это непрерывный процесс, которому требуется пристальное внимание. Только в случае комплексного подхода к безопасности, включающего в себя обязательное использование технических средств и организационных мер, ваш сайт будет надежно защищен.

Автор: 1С-Битрикс

Источник

www.pvsm.ru

Как происходит взлом, и что делать, если сайт взломали?

Безопасность сайта зависит от многих факторов, в том числе человеческого (работы службы поддержки хостинга, имеющей контроль над сервером). Это второй пост в рубрике Безопасность.

Взломать сайт могут:

Чаще взломом сайта занимаются программы-боты, которые обходят Интернет и для каждого сайта на CMS производят стандартное тестирование и попытки взлома.

Какие уязвимости используют боты-взломщики

Взлом в автоматическом режиме осуществляется:

Более сложные способы взлома, которые производятся при участии хакера (не автоматически):

Таким образом, если вы владеете сайтом с низкой посещаемостью, то вам достаточно защититься от ботов и разместить сайт на надёжном сервере, на котором не случится массового взлома сайтов. Если у вас очень популярный сайт, то нужно прилагать дополнительные усилия для обеспечения его безопасности, потому что к ресурсу будут обращаться многие хакеры лично.

Мои сайты с очень низкой посещаемостью взламывали:

На CMS WordPress - все 8 сайтов на разных хостингах, с размещением рекламы в футере и с переходом на сайт хакера при клике по любой ссылке, а также с автоматической переадресацией через iframe - возможно, из-за ущербности этой CMS, возможно из-за неправильных прав на файлы и папки, но взломали все сайты на этой CMS.На самописной CMS без бд - с размещением .htaccess вируса для мобильных и с выпадом сайта из поиска - из-за взлома сервера risp.ru, который оказался не только дешёвым, но и ненадёжным.На CMS Drupal - на хостинге бегет, с размещением рекламного баннера знакомств в углу в стиле ВК-сообщения, который появлялся только в вечернее время - по непонятным причинам, возможно, из-за прав на папки и присутствие модуля Devel или других ненадёжных, или из-за уязвимости версии Drupal 7.36 и долгого не обновления.На CMS Drupal из коробки - эти сайты имели включенные неиспользуемые сложные модули, типа rules, commerce... - взлом произошёл из-за этих модулей или из-за ненадёжного хостинг-сервера Aghost (админом было предложено установить доп. защиту после инцидента).

Политика безопасности

Приходится тратить время не только на развитие сайта, но и на его защиту и регулярное изучение уязвимости, поиск и обнаружение вирусов.Бэкапы сайта - не только возможность восстановления работы и отката назад к рабочему состоянию, но и возможность анализа изменённых вирусом файлов.Безопасность не терпит изъянов - если вы знаете об уязвимости, её обязательно нужно закрыть. Любой защищённый сайт всё равно не безопасен на 100%, поэтому известные Администрации уязвимости точно должны исключаться.Обязательно нужно выбрать надёжный хостинг, и менять хостинг на более дорогой и безопасный при увеличении популярности сайта, ужесточении требований к надёжности работы.Роли и права пользователей должны иметь строгие разграничения, внедряемые новые функции обязательно должны интегрировать функции разграничения доступа по ролям.Сложные проекты потребуют более сложных правил политики безопасности, чётких рекомендаций не бывает.

Итак, сайты точно взламывают, допустим это произошло с вашим сайтом, что делать?

Что делать после взлома сайта?

Вначале нужно очистить сайт от вирусов, и только потом менять пароли администратора и других пользователей, имеющих критический уровень доступа. Тем не менее, пароли электронных адресов, пароля от компьютера, ftp-пароли, хостинга можно менять сразу.

Обычно взлом предполагает добавление вирусных файлов, и очень редко sql-инъекций. Во всяком случае, для большей надёжности хакер размещает вирусные файлы, чтобы получить доступ снова, когда администратор удалит инъекции. Поэтому нужно чистить сайт от вирусов.

1. Чистка сайта от вирусов

Проверить права на файлы и папки, обычно 755 для папок и 644 для файлов - заново установить для всех файлов и папок такие права (на некоторых хостингах может быть 600 для файлов и 700 для папок)Проверить файл index.php в корне сайта - обычно там добавляется shell-программа - сравнить index-ный файл с прежними версиямиПроверить .htaccess в корне сайта - там могут добавляться правила переадресации, например для мобильных или для всех пользователейПроверить наличие новых папок в корне и в подпапкахПроверить папку временных файлов и папку, в которую разрешена записьПроверить наличие новых файлов с странными названиями (иногда обычными названиями): обычно с расширением php, иногда и неисполняемые файлы могут содержать вирусы: картинки, текстовые файлы, js,Проверить наличие новых файлов .sh - это файлы, которые могут содержать bash-коды и shell-вирусы,Проверить старые php-файлы на вирусные вставки.

Следующие сервисы помогают определить вирусы, найти php, js, shell инъекции:

https://www.virustotal.com/ru/ - онлайн сканер вирусов, можно закачать бекап сайта или указать url.http://revisium.com/ai/ - AI-Bolit - мощный сканер вирусов, работающий со всеми популярными CMS, написан на php.http://santivi.com/ - Санти - антивирус для сайтов, написанный на php, имеет версию Windows-приложение.http://www.rfxn.com/projects/linux-malware-detect/ - Linux Malware Detect - сканнер сайта, обнаружение различных видов вирусовhttps://github.com/novostrim/watcher4site - Watcher4site - поиск изменённых сайтов.https://sitecheck.sucuri.net/ - Sucuri - онлайн-проверка сайта на вирусыhttps://github.com/emposha/PHP-Shell-Detector - Web Shell Detector - мощный поиск инъекций php/cgi(perl)/asp/aspxhttp://2ip.ru/site-virus-scaner/ - онлайн проверка вирусов на сайте

После обнаружения вирусов - удалить вирусные файлы, заменить заражённые файлы на чистые из бекапа.

2. После чистки сменить пароли

Пароли учётной записи администратора, редакторов, других пользователей, возможно, обновить пароли всех простых пользователей или ограничить их права.Сменить ftp-пароли, почистить компьютер от вирусов, сменить ОС.

Если вирусы появляются снова, попробуйте перенести сайт на другой хостинг на время. Если ситуация повторится - ищите уязвимости.

3. После смены паролей - обновить систему

Если сайт на популярной CMS - обновить ядро и все модули.

Отключить неиспользуемые модули.

Проверить код самописных модулей.

4. После обновления читать логи, искать уязвимые места

Эта работа самая сложная. Но если не залатать дыры безопасности, развитие проекта будет невозможным - вирусы будут съедать вашу работу с сайтом, заставляя производить чистку, смену паролей и прочие не целевые действия.

Изучить следующие логи:

Что конкретно там нужно смотреть: чужие ip, с которых производился доступ, работа bash-скриптов, php-скриптов.

Если не обнаружена активность хакера, при невозможности чтения логов:

Отключить небезопасные модули.Отключить регистрацию.Ограничить функции сайта.Ожидать появление вируса снова и находить уязвимые места в сайте с ограниченными функциями.

Обратитесь к тех. поддержке хостинга за бесплатным поиском вирусов или уязвимости или предложите оплату за обеспечение безопасности.

Если никакие действия не помогают найти уязвимое место, в том числе, не помогает смена хостинга, придётся перенести сайт на другую CMS: более надёжную или самописную.

Защита сайта на Drupal

Друпал надёжен сам по себе. Только использование непроверенных модулей, ошибки программиста, создающего свои модули для сайта, также ошибки настройки сервера или несоблюдение основ безопасности Друпал могут быть причиной взлома. Также не рекомендуется ставить Друпал из коробки, в том числе Kickstarter и прочие готовые решения на Друпал. Что поможет сделать безопасной CMS Drupal:

https://hackertarget.com/drupal-security-scan/ - онлайн сканер друпал на вирусыHacked! - модуль поиска изменённых файлов ядра и контрибных модулей, шаблоновSecurity Review - поиск уязвимостейSecure Code Review - анализ уязвимости кодаCoder - определяет соответствие кода сайта стандартам написания программ для Drupal

Что поможет сделать сайт наиболее надёжным?

  1. Собственный сервер VDS или хотя бы VPS - вместо шаред-хостинга
  2. Использование самописной CMS от надёжного разработчика
  3. Надёжные пароли ftp, базы данных, админа
  4. Разграничение прав доступа к действиям на сайте и страницам администрирования
  5. Отказ от сложных функций с непроверенными кодами или модулями

Где узнать о безопасности и защите сайтов

http://tlito.ru/node/58 - безопасность Drupalhttp://tlito.ru/node/168 - обеспечение безопасности при разработке сайтаhttps://help.yandex.ru/webmaster/protecting-sites/basics.xml - основы безопасности от Яндексhttps://yandex.ru/support/webmaster/security/protecting-site.xml - как защитить сайт от зараженияhttp://habrahabr.ru/post/12067/ - основы безопасности PHP

Резюме

Если ваш сайт - это Интернет-адрес, на котором размещён набор функций и контент, а также присутствуют пользователи, то это всегда будет оставаться с вами. Взлом только ломает функции, но не уничтожает проект полностью. Поэтому, в любом случае, вы можете повторить проект на новой CMS, новом адресе, используя наработанный прежде опыт.

Защищайте сайт, чтобы решение о смене CMS, хостинга, адреса, политики развития ресурса было собственным решением Администрации ресурса, а не принятым в условиях форс-мажора, давления, угроз, шантажа или даже судебных исков.

Да, кстати, за действия хакеров, взломавших сервер, и причинённый пользователям вред ответственность несёт Администрация Интернет-сайта. Поэтому не стоит хранить любую личную информацию, платёжную информацию или предлагать любые функции, которые принесут урон пользователям после взлома сайта хакером.

Вопросы размещайте в вопросах и ответах.

www.tlito.ru

Prostoy-Site | Все права защищены © 2018 | Карта сайта