🚨 Введение: больше, чем визуальная оболочка 🌐

• При проведении экспертизы сайта большинство заказчиков в первую очередь думают о текстах, изображениях и, возможно, о видеозаписях. Однако реальная доказательственная база (и ценные улики для спора) часто скрывается в технических дебрях: журналах сервера, WHOIS-записях, исходном коде, SSL-сертификатах и даже в robots.txt. Опытный эксперт способен извлечь максимум информации из этих источников, даже если визуальный контент был удален или изменён.
• Настоящая консультация, подготовленная в техническом стиле, содержит систематизированный перечень объектов исследования при экспертизе сайта (помимо, собственно, текстового и графического контента).

Раздел 1. Доменное имя и регистрационные данные 🏷️

1.1. WHOIS-данные: «паспорт» домена

WHOIS (Who Is) — это протокол получения информации о регистранте доменного имени. Включает:

Что может установить эксперт:

• Кто является (или являлся) владельцем домена на интересующую дату.
• Не был ли домен перерегистрирован (изменён registrant) незадолго до инцидента (возможно, с целью сокрытия).
• Дата создания домена (например, сайт мошенников часто создаётся за 1-2 дня до рассылки фишинговых писем).

Где взять данные: WHOIS-сервисы (whois.ru, whois.domaintools.com), но для суда требуется нотариально заверенный протокол осмотра — в том числе и самих WHOIS-данных. Эксперт может сделать выборку из архивов WHOIS (например, сервис «История домена»).

1.2. История домена (WHOIS history)

Позволяет увидеть, кто владел доменом ранее, даже если текущий registrant скрыт.

Важно: Если на момент спора Privacy Protection (скрытие данных) включена, эксперт может запросить у регистратора раскрытие данных (по судебному запросу, ст. 57 ГПК РФ).

1.3. DNS-записи (A, MX, TXT, CNAME)

DNS-записи связывают домен с IP-адресом сервера.

Что может установить эксперт: в какой хостинг был направлен домен, когда менялись DNS-записи (возможно, сайт переезжал с одного сервера на другой). Это особенно важно, если владелец домена утверждает, что он не имеет отношения к контенту (например, лендинг мошенников), а оказывается, что DNS-записи вели на личный VPS обвиняемого.

Раздел 2. Серверная инфраструктура (хостинг) 🖥️

2.1. IP-адрес и геолокация

• Определение физического местоположения сервера (страна, дата-центр).
• Установление хостинг-провайдера.

Значение: может подтвердить, что сайт (даже если сейчас «упал» или удалён) в момент инцидента находился на серверах, арендованных определённым лицом.

2.2. Тип хостинга и конфигурация

• Shared (shared hosting), VPS/VDS (виртуальный выделенный сервер), Dedicated (физический), Cloud (AWS, DigitalOcean, VK Cloud, Яндекс.Облако).
• Имя виртуального сервера (hostname), операционная система (Linux, Windows), версия ядра.

2.3. Панели управления (cPanel, ISPmanager, Plesk, Vesta CP)

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

2.4. SSL-сертификат

Что может установить эксперт: когда был выдан сертификат, на какое доменное имя, какому лицу/организации. Это может помочь идентифицировать владельца сайта, даже если WHOIS скрыт.

2.5. Резервные копии сайта (backups)

Даже если сайт был удалён или изменён, резервная копия (если сохранилась на сервере или у провайдера) может содержать оригинальные файлы, базу данных, логи.

Важно: Эксперт может попытаться восстановить данные даже из «удалённых» бэкапов, если они не были перезаписаны.

Раздел 3. Логи сервера 📊

Логируются практически все события, происходящие на сервере. Для экспертизы наиболее ценны:

3.1. Логи доступа (access logs)

Фиксируют каждый HTTP-запрос:

• IP-адрес клиента (посетителя).
• Время запроса (timestamp).
• Запрошенный URL (страница, изображение, файл).
• HTTP-метод (GET, POST, PUT, DELETE, HEAD).
• HTTP-статус ответа (200 OK, 404 Not Found, 403 Forbidden, 500 Internal Server Error).
• User-Agent (браузер, операционная система).
• Referer (с какого сайта перешли).

Что может установить эксперт:

• Кто (IP) и когда посещал сайт (в том числе злоумышленник, администратор, автор вредоносного контента).
• Какие страницы загружались, какие файлы скачивались.
• Были ли попытки взлома (например, подбор пароля admin, SQL-инъекции в параметрах URL).
• Если IP-адрес принадлежит конкретному лицу (по запросу к провайдеру), это можно идентифицировать.

3.2. Логи ошибок (error logs)

• «PHP Fatal error», «MySQL connection timeout», «500 Internal Server Error».
• Даты и время ошибок.
• Стек вызовов (stack trace), иногда содержащий пути к файлам на сервере.

Значение: могут указывать на нестабильность работы, уязвимости, а также на попытки эксплуатации уязвимостей (например, внедрение вредоносного кода).

3.3. Логи FTP / SFTP (доступ к файлам)

Если администраторы подключались к серверу по протоколу передачи файлов (FTP, SFTP) для редактирования сайта:

• IP-адрес, с которого подключались.
• Время соединения.
• Какие файлы загружались, изменялись, удалялись.
• Учётная запись (логин).

Значение: можно установить, кто именно загрузил (или удалил) вредоносный файл.

3.4. Логи SSH (администрирование сервера)

Если сервером управляли через протокол удалённого доступа (SSH, в Linux-среде), логи содержат:

• IP-адрес администратора.
• Введённые команды (история bash_history), если удалось сохранить.

3.5. Логи панели управления CMS (WordPress, Joomla, Drupal, 1С-Битрикс)

• Входы в админку (логин администратора, IP, время).
• Изменения контента (кто, когда, какую статью/страницу правил).
• Установка и удаление плагинов/модулей.
• Создание новых пользователей с правами admin.

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

Раздел 4. Программное обеспечение сайта (исходный код и база данных) 💾

4.1. Система управления содержимым (CMS)

• Определение типа (WordPress, 1С-Битрикс, Joomla, Drupal, ModX, Tilda, Wix, самописная CMS).
• Версия (например, WordPress 5.8.3).

Значение: если CMS не обновлялась (версия устаревшая), это может свидетельствовать о пренебрежении безопасностью, что важно при спорах о взломе.

4.2. Исходный код (frontend)

• HTML, CSS, JS, TypeScript.

Что можно найти: скрытые ссылки, недокументированные функции, вредоносные скрипты (биткойн-майнер, подмена криптовалютных адресов), код, загружающий контент с другого сайта (крос-доменный).

4.3. Исходный код (backend)

• PHP, Python (Django/Flask), Ruby on Rails, Node.js, Java (JSP), C# (ASP.NET).

Что можно найти: бэкдоры (вредоносные файлы с именами shell.php, cmd.php, adminer.php), SQL-уязвимости (конкатенация строк в запросе), незащищённые API-ключи, пароли к базе данных в открытом виде (plaintext). При анализе оценивается безопасность кода.

4.4. База данных (структура и содержимое)

• Таблицы пользователей (логины, хэши паролей, email).
• Таблицы контента (статьи, посты, комментарии, заказы).
• Журналы изменений (audit logs) внутри БД.

Что можно установить: кто и когда создал ту или иную запись, в каком порядке правки, существовал ли удалённый вредоносный контент. Если сайт был взломан и злоумышленник добавил ссылки на порносайты, то в БД сохранится пользователь (кто вносил правку) — обычно это администратор сайта (если его учётная запись не была взломана).

4.5. robots.txt,.htaccess, nginx.conf

• Файлы конфигурации веб-сервера.

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

4.6. Cron-задачи (запланированные задания)

Сервер может автоматически выполнять скрипты (например, очистку кэша, рассылку новостей, резервное копирование). Если cron запускает вредоносный скрипт (скрытый), эксперт может найти его следы в логах cron и по временным меткам созданных файлов.

4.7. Веб-аналитика (Google Analytics, Яндекс.Метрика, LiveInternet, Hotjar)

Даже если сам сайт уже недоступен, данные аналитики (отчёты о посещаемости, источниках трафика, достигнутых целях) могут сохраняться в аккаунтах владельцев. Эксперт (по доверенности) может запросить доступ к этим данным или дать задание заказчику выгрузить их в формате Excel / CSV.

Что можно установить: сколько человек посетило сайт, с каких IP-адресов, какие страницы просматривали, когда была последняя активность.

Раздел 5. Дополнительные источники данных (внешние сервисы) 🌍

5.1. Сервисы архивации веб—страниц (Internet Archive Wayback Machine, Archive.is)

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

Что можно восстановить: удалённые статьи, фотографии, скриншоты, CSS-стили.

Важно: архивные копии имеют доказательственную силу (суды принимают их как нотариально заверенные).

5.2. Кэш поисковых систем (Google Cache, Яндекс.XML Cache, Bing Cache)

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

5.3. Сервисы WHOIS истории (DomainTools Historical WHOIS, WHOIS History API)

Позволяют посмотреть, кому принадлежал домен ранее, даже если сейчас WHOIS скрыт (privacy protection).

5.4. Мониторинг доступности сайта (uptime-мониторы)

Если сайт отслеживался через сторонние сервисы (например, UptimeRobot), можно получить историю доступности и даты сбоев.

5.5. Информация о CDN (Cloudflare, Akamai, Amazon CloudFront, VK CDN)

Если сайт использует сеть доставки контента (CDN), у провайдера CDN хранятся логи запросов и кэшированные версии страниц, которые могут быть истребованы по судебному запросу.

Раздел 6. Что нужно предоставить эксперту (чек-лист) 📋

Заключение 🎯

При экспертизе сайта объектами исследования являются не только видимые тексты и изображения, но и:

• Доменные данные (WHOIS, DNS, история) — для идентификации владельца и даты создания.
• Серверная инфраструктура (IP, хостинг, SSL, конфигурация) — для установления местоположения и юрисдикции.
• Логи сервера (access, error, FTP, SSH) — для реконструкции событий, посещений, определений IP-адресов злоумышленников.
• Программный код (исходники, CMS, база данных) — для поиска вредоносных функций, бэкдоров, SQL-инъекций.
• Внешние архивы (Internet Archive, WHOIS history) — для восстановления удалённого контента.

Для проведения полноценного исследования необходимо предоставить эксперту максимально широкий доступ (логи, сервер, БД) или, хотя бы, резервные копии. Чем больше источников данных, тем точнее будет заключение.

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

👉 https://medeksp.ru/ 👈

Минутка юмора 🙂

Другие шутки