2 заметки с тегом

Чек-листы

/core.php, line 2
Error 2: Use of undefined constant k - assumed 'k' (this will throw an Error in a future version of PHP)

/core.php, line 2
Error 2: Use of undefined constant k - assumed 'k' (this will throw an Error in a future version of PHP)

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

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

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

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

Причины взлома

Логично начать с того, что же все таки приводит к взлому сайта. Существует три основные причины:

  1. Скомпрометированы данные для доступа серверу (хостинг, FTP, SSH) или в панель администрирования сайта.
    Многие пользователи сохраняют пароли в браузере или FTP клиенте. Вирус может похитить данные для доступа и переслать злоумышленнику.
  2. Устаревшие версии CMS и установленных плагинов.
    Часто сайт работает на старой версии CMS, плагины не обновляются, а значит найденные и закрытые разработчиками в новых версиях уязвимости присутствуют на сайте.
  3. Сайт расположен на виртуальном хостинге и веб-сервер не безопасно настроен.
    Необходимо ответственно подходить к выбору хостинга. Для большей безопасности лучше воспользоваться VDS или облачным хостингом, в этом случае имеется возможность настроить сервер так как потребуется. Как выбрать хостинг написано в посте «Где разместить свой сайт?»

Последствия

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

Поиск следов

Прежде чем приступить к процессу поиска следов взлома нужно разобраться как злоумышленник получает доступ к серверу.

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

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

1. Поменять пароли.

В первую очередь необходимо поменять все пароли: хостинг, FTP, SSH, панель администрирования сайта. Проверить нет ли новых пользователей с правами администратора.

2. Изучить логи доступа.

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

Если с сайта рассылается спам, таким же способом проверяются логи почтового сервера.

3. Проверить файлы .htaccess.

В первую очередь необходимо проверить их на наличие директив auto_append_file и auto_prepend_file, которые позволяют подключить php файлы в начале и конце php скриптов. Для этого используются следующие команды терминала:

find . -type f -name '\.htaccess' | xargs grep -i auto_prepend_file
find . -type f -name '\.htaccess' | xargs grep -i auto_append_file

Так же не лишним будет найти файлы .htaccess, которые содержат «http». Результатом поиска будет список всех правил перенаправлений:

find . -type f -name '\.htaccess' | xargs grep -i http

И последнее — проверить использование «HTTP_USER_AGENT»:

find . -type f -name '\.htaccess' | xargs grep -i HTTP_USER_AGENT

4. Проверить наличие iframe на страницах сайта.

При помощи инструментов разработчика в браузере (Chrome или Firefox) необходимо проверить код страниц на наличие iframe, их часто вставляют на взломанные сайты.

5. Найти недавно изменённые файлы.

Найти файлы, которые редактировались, например, за последнюю неделю можно следующим образом:

find . -type f -name '*.php' -mtime -7

Временной промежуток задаётся параметром mtime.

Необходимо проверить эти файлы на наличие вредоносного кода. Если команда ничего не выдаёт, то скорее всего взломщик воспользовался FTP или SSH.

6. Проверить файлы на подозрительный код.

Следующие команды ищут файлы, содержащие атакующие сценарии — вхождения строк eval, base64_decode, gzinflate и str_rot13:

find . -type f -name '*.php' | xargs grep -l "eval *(" --color
find . -type f -name '*.php' | xargs grep -l "base64_decode *(" --color
find . -type f -name '*.php' | xargs grep -l "gzinflate *(" --color
find . -type f -name '*.php' | xargs grep -l "str_rot13 *(" --color

Можно расширить эту команду для поиска функций, которые могут быть использованы злонамеренно, такие как mail, fsockopen, pfsockopen, stream_socket_client, exec, system и passthru:

find . -type f -name '*.php' | xargs egrep -i "(mail|fsockopen|pfsockopen|stream_socket_client|exec|system|passthru|eval|base64_decode|gzinflate|str_rot13) *\("

Эта команда помогает найти файлы, в которых для маскировки вредоносного кода используется preg_replace:

find . -type f -name '*.php' | xargs egrep -i "preg_replace *\((['|\"])(.).*\2[a-z]*e[^\1]*\1 *," --color

Так же find можно использовать для поиска шестнадцатеричных кодов в php файлах:

find . -type f -name '*.php' | xargs grep -il x29

Например x29 — это код закрывающей скобки, а x3B — точка с запятой, в некоторых случаях это полезно.

7. Проверить каталоги, доступные для загрузки.

Особо тщательно, используя указанные в пункте 5 команды, необходимо исследовать каталоги, в которые доступна загрузка. Так же можно проверить их на наличие файлов с определенным расширением. Например, вряд ли в папке uploads должны быть php-скрипты:

find uploads -type f -name '*.php'
find uploads -type f | xargs grep -i php

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

find uploads -type f -iname '*.jpg' | xargs grep -i php

7. Сравнить код с чистым дистрибутивом CMS той же версии.

Если есть такая возможность, то это хороший способ найти изменения. Удобно использовать системы контроля версий, например, для git можно воспользоваться командой:

diff -r dist/ mysite/ -x upload

8. Поиск кода в базе данных.

Не стоит упускать из виду то, что вредоносный код мог проникнуть в базу данных. Её так же необходимо проверить на наличие атакующих сценариев, таких как %base64_decode(%, %eval(%, %gzinflate%, %str_rot13%, %iframe% и т. п.

Как видите, устранить последствия взлома довольно сложная задача. Поэтому следите за своим сайтом и следуйте нашим рекомендациям.

Узнать больше об услуге «Техническая поддержка» можно на основном сайте веб-студии Хамелеон здесь.

2017   Безопасность   Чек-листы

Как составить техническое задание на разработку сайта

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

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

Задач, которые выполняет техническое задание, несколько — от приведения мыслей в порядок, до разрешения споров между нами и заказчиком.

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

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

  1. ГОСТ 34
  2. ГОСТ 19
  3. IEEE STD 830-1998
  4. ISO/IEC/ IEEE 29148-2011
  5. RUP
  6. SWEBOK, BABOK и пр.

Основываясь на этих стандартах и на собственном опыте мы пришли к следующей структуре технического задания:

1. Общие положения

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

2. Цели и задачи

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

3. Типы данных

Этот раздел содержит перечень сущностей, которые используются в проекте. Для каждого типа данных описывается набор необходимых характеристик. Например, «Товар» содержит характеристики «Фотография», «Название», «Артикул» и «Описание».

4. Функциональные характеристики

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

5. Страницы

Раздел с описанием всех страниц сайта. Описать нужно как можно подробнее, при этом удобно ссылаться на типы данных. Так же желательно обращать внимание не только на то, как отображаются отдельные элементы интерфейса, но и на то, как они работают. Хорошо, если данный пункт подкрепляется прототипами страниц.

6. Требования к надёжности

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

7. Требования к хостингу

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

8. Наполнение контентом

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

9. Сдача и приёмка

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

Общие рекомендации

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

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

2017   Бизнес-процессы   Чек-листы