Главная страница Случайная страница
Разделы сайта
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!
Смотрим логи
|
|
Журналы веб-сервера, МySQL и системные — просто кладезь информации по свалившей ся проблеме. Изучая их, мы должны попытаться получить ответы на вопросы: что именно произошло, кто атакует и где искать проблему. В зависимости от настроек в логах возможна разная детализация данных, но обычно установок по умолчанию вполне достаточно, чтобы ухватиться за ниточку.
Вероятно, най ти ответ, как именно проникли, в большом объеме сразу не получится, так как, скорее всего, атака будет идти большим потоком, но некоторые выводы все равно можно сделать. Если была настроена система мониторинга, за точку отсчета можно взять увеличение нагрузки на узел и рост сетевого трафика. Как правило, с некоторого момента графики идут вверх. Ответ на вопрос, что произошло, ищем до этого времени, проблемные места — после.
Начинать, конечно, нужно с логов веб-сервера. Журналы смотрим как вручную, так и при помощи различных инструментов. Первый способ медленнее, но мы не пропустим нужное, второй способ позволяет увидеть ситуацию в общем. В начале атаки в логах можно увидеть множество запросов вроде
| " GET /wp-admin/admin-ajax.php? action=getfile& amp; /../../wp-config.php" |
Причем хакер просто запускает целый пакет из подобных запросов, которые идут в том числе и к отсутствующим на сай те темам и плагинам. Именно поэтому следует убирать все лишнее. Ведь неактивная тема при неправильных правах может стать проблемой. После того как атака будет успешной, в логах появится много POST-запросов:
| " POST /wp-content/themes/default/user.php" |
Именно так отдаются команды. Такие фай лы нужно проверять, удалять или чистить. IP, с которых идет атака, анализируем вживую:
| $ tail -f /var/log/apache2/access.log | grep & lt; IP-адрес& gt; $ cat /var/log/apache2/access.log | grep & lt; IP-адрес& gt; |
И отправляем на блокировку iptables. Ищем в логах обращения к «запрещенным» фай лам и каталогам сай та (wp-config.php, wp-admin, wp-login.php,.htaccess). Также проверяем все запросы, содержащие слова: mysql, function, connect, base64_decode, document.write, DOCUMENT_ROOT и так далее. Ничто не мешает составить команды для быстрого отбора нужных данных.
Например, выведем только IP и URL, к которым они получали доступ, подсчитаем и рассортируем:
| $ cat /var/log/apache2/access.log | awk '{print $1" " $7}' | sort | uniq -c | sort -rg |
Вставив перед вызовом awk grep -i POST, можем отобрать только POST-запросы. Если добавить в конец команды | grep wp-login.php, мы увидим, сколько раз с IP пытались подключиться к определенному URL.
Аналогично можем отследить ошибку 404, при нормальной работе их процент минимален. Рост в начале атаки свидетельствует не только о том, что кто-то пытается най ти то, чего нет, а в конце атаки говорит о нарушении работы сай та из-за поломанных скриптов. Соответственно, когда ошибок 404 станет меньше, это значит, что от сай та отстали. Просмотреть общее количество ответов сервера с разным статусом можно так:
| $ cat /var/log/apache2/access.log | awk ' { print $9 } ' | sort | uniq -c |
Для заархивированных логов вместо cat используем zcat. В зависимости от настроек журналирования придется чуть поэкспериментировать с запросами, но такая небольшая автоматизация значительно сокращает время на общий анализ.
Также можно использовать в работе многочисленные программы для анализа логов веб-серверов. Например, утилита GoAccess позволяет строить самые разные отчеты как в интерактивном виде, так и генерируя HTML/JSON/ CSV-фай л. С его помощью можно быстро обнаружить аномалию, не прибегая к самостоятельному построению запроса.
| $ sudo apt install goaccess |
В самом простом случае указываем фай л. При запуске понадобится подобрать формат журнала сервера.
| $ goaccess -f /var/log/apache2/access.log |
В результате получаем интерактивную таблицу с процентом уникальных посетителей, топ URL, запросы 404, IP хостов и так далее. Чтобы раскрыть секцию полностью, следует нажать соответствующую ей цифру (shift + 0–1 для 11–20 секций) и букву O. Чтобы закрыть, нажимаем q. При необходимости можно комбинировать запуск GoAccess с grep, awk, sed и прочим. Например, получим список IP, которые стучатся в админку, и сохраним его в фай л.
| $ grep -i wp-login.php /var/log/apache2/access.log | goaccess -a & gt; report.html |
Меняем на wp-config.php и смотрим, кто пытается получить этот фай л.
В Win можно использовать Apache Logs Viewer — очень наглядный инструмент, который подсвечивает разным цветом запросы с разным статусом, показывает страну источника и позволяет быстро фильтровать, отбирать и сортировать данные, строить отчеты.
В контексте журналов хотелось бы упомянуть еще один плагин iThemes Security, который имеет много полезных функций: отслеживание 404, защиту от брутфорса (блокировка через.htaccess), контроль изменений фай лов, блокировку записи основных фай лов, бэкап базы данных, бан-лист, подстрой ку защитных функций и много другого. Но самое полезное — это вкладка «Логи», в которой выводятся отчеты по 404, блокировки, IP, пытавшиеся залогиниться. Причем выводится сразу и логин, с которым пытаются подключиться, что само по себе полезно, в логах Apache нет этой информации. То есть не нужно искать все это в журналах веб-сервера, а все на виду.
ПОЛЬЗОВАТЕЛЬ «АДМИНИСТРАТОР»
Журнал iThemes Security показал большое количество попыток подключения с логином admin с разных IP, поэтому стоит переименовать эту учетную запись (если это не сделано при установке блога) вручную в базе данных при помощи SQL-запроса или при помощи плагинов. Также стоит для повседневной работы завести отдельную учетную запись с меньшими правами (роль редактора или автора), использовав роль администратора только при обслуживании движка.
Это уменьшит вероятность слить данные при появлении очередной уязвимости. Используя уязвимости, атакующий попробует создать учетную запись с ролью администратора. Поэтому следует сразу посмотреть во вкладке «Пользователи», применив фильтр (wp-admin/users.php? role=administrator). Проблема в том, что все пользователи в этой вкладке не будут отображены. Так, счетчик показывал три записи, но выводилась только одна.
Информация о логинах и ролях хранится в двух таблицах: wp_users и wp_ usermeta. Смотрим имя базы данных в wp-config.php. Заходим в консоль MySQL и выбираем базу:
| $ MYSQL -uadmin -p mysql& gt; USE database; |
Выводим список ролей:
| mysql& gt; SELECT * FROM wp_usermeta WHERE meta_key LIKE " wp_capabili- ties"; |
Нас интересуют те user_id, у которых значение wp_capabilities установлено в a: 1: {s: 13:»administrator»; b: 1; }.
Проверяем имя:
| mysql& gt; SELECT * FROM wp_users WHERE ID = 1024; |
Удаляем:
| mysql& gt; DELETE FROM wp_users WHERE ID = 1024; |
Обычно нет необходимости, чтобы MySQL веб-сай та был доступен из Сети. Проверяем порт:
| $ netstat -ant | grep 3306 tcp 0 0 0.0.0.0: 3306 0.0.0.0: * LISTEN |
Если получаем такой результат, то правим /etc/mysql/my.cnf, добавив туда строку skip-networking или bind-address = 127.0.0.1, и перезапускаем MySQL.
Дополнительно можно прикрыть порт MySQL фай рволом:
| $ sudo iptables -I INPUT -d 127.0.0.1/8 -j ACCEPT $ sudo iptables -A INPUT -p tcp --dport 3306 -j DROP |
|
|