Как найти пароль в логах

Время на прочтение
9 мин

Количество просмотров 8.4K

Знаете ли вы что хранится в вашем git репозитории? Нет ли среди сотен коммитов паролей от продуктовых серверов, попавших туда по ошибке?

А что если ansible скрипт при публикации упадет и засветит пароли в логе?

Рассказываю о том как мы попробовали автоматизировать такие проверки и что из этого получилось.

Привет, Хабр!

Меня зовут Олег, я работаю в достаточно крупном для РФ банке, в подразделении «IT для IT».

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

Исторически у нас есть 2 git хранилища (на самом деле больше, но это не так важно), в одном команды хранят свой код, в другом хранятся скрипты деплоя, конфигурации приложений итд, в общем все что относится к OPS составляющей.

Так вот, исходя из принятого процесса скрипты и конфигурации для промышленных сред хранятся в master ветке и при вливании в нее нужен апрув от OPS. 

Почему именно так? Потому что кроме всего там же в git хранятся и пароли от сред (хоть и зашифрованные) и отвечают за них OPSы. Если какой то пароль засветится в логе Jenkins или попадет в открытом виде в git — это серьезная утечка и безопасность придет (с паяльником) именно к OPS.

Пароли в git? Серьезно?

Да, к сожалению серьезно. Конечно же для таких вещей нужно использовать системы secret management, такие как HashiCorp Vault, CyberArk Conjur итд.

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

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

Значит, будем автоматизировать!

Что анализируем?

Совместно с коллегами выявили 3 основных вектора утечки пароля, которые их интересовали и встречались наиболее часто:

Пароль в открытом виде 

---
    dev_ssh_username1: "admin"
    dev_ssh_password1: "admin123"

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

Передача параметров в shell или command таски ansible

- name: Deploy
  hosts: all
  tasks:
    - name: Update
      shell: "update.sh --user={{ update_user }} --password={{ update_password }}"

Тут опасность заключается в том, что если playbook будет вызван с -v то мы получим в логах наши секреты в открытом виде.

$ ansible-playbook deploy.yml -i env/DEV/hosts -v
TASK [Update] ******************************************************************
changed: [192.168.1.2] => {"changed": true, "cmd": "/home/dev/update.sh --user=secret_user --password=secret_password", "delta": "0:00:05.056532", "end": "2020-11-06 09:53:09.397355", "rc": 0, "start": "2020-11-06 09:53:04.340823", "stderr": "", "stderr_lines": [], "stdout": "Update SUCCESS", "stdout_lines": ["Update SUCCESS"]}

Или, если playbook упадет то в логе выведется строка с секретами (даже если не указывать -v)

$ ansible-playbook deploy.yml -i env/DEV/hosts
TASK [Update] ******************************************************************
fatal: [192.168.1.2]: FAILED! => {"changed": true, "cmd": "/home/dev/update.sh --user=secret_user --password=secret_password", "delta": "0:00:00.018710", "end": "2020-11-06 10:14:30.642419", "msg": "non-zero return code", "rc": 127, "start": "2020-11-06 10:14:30.623709", "stderr": "/bin/sh: /home/dev/update.sh: Нет такого файла или каталога", "stderr_lines": ["/bin/sh: /home/dev/update.sh: Нет такого файла или каталога"], "stdout": "", "stdout_lines": []}

Чтобы этого избежать можно использовать environment, например:

- name: Deploy
  hosts: all
  tasks:
    - name: Update
      shell: "/home/dev/update.sh $AUTH_DATA"
      environment:
        AUTH_DATA: "--user={{ update_user }} --password={{ update_password }}"

Тогда в вывод наши credentials не попадут. Еще можно указывать атрибут no_log.

Неосторожное использование withCredentials

У нас используется Jenkins, в котором для работы с credentials используется конструкция withCredentials. С помощью нее внутри pipeline можно получить credential, сохранить его в переменные и использовать, например для подключения к какой нибудь сторонней системе. Jenkins при этом будет маскировать в логе значение этих переменных.

Однако, если мы сделаем, например так:

node {
  stage('Jenkins Credentials | Decrypt Secret File') {
    withCredentials([file(credentialsId: 'credentials-id', variable: 'secretFile')]) {
      sh 'cat $secretFile'
    }
  }
}

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

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

Ищем пароли

Казалось что поиск паролей в открытом виде это какая то плевая задача. У нас в арсенале есть не только SonarQube но и Checkmarx. Уж они точно должны уметь решать эти задачи.

И вроде бы вот оно — есть такое правило для SonarQube Hard-coded credentials are security-sensitive

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

C Checkmarx оказалась так же картина — реагирует он очень выборочно. И правила там тоже очень простые (коллеги из Application Security рассказали). Например, такой код пропускает:

import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.bind.annotation.RestController;
 
@RestController
public class DemoController {
    @RequestMapping("/show_me_creds")
    public @ResponseBody String show_me_creds() {
        String thisIsMyLittleSecret = "qwerty12345";
        return thisIsMyLittleSecret;
    }
}

Изучив что есть на рынке пришли к выводу что будем смотреть в сторону opensource утилит. Запрос в google «find secrets in git» выдает нам примерно такие варианты:

• https://github.com/awslabs/git-secrets/blob/master/README.rst

• https://github.com/dxa4481/truffleHog/blob/dev/README.md

• https://github.com/Yelp/detect-secrets

• https://github.com/zricethezav/gitleaks

Попробовав их все мы остановились на Gitleaks, вот почему:

• Проводит анализ на основе regexp, которые можно расширять;

• Умеет учитывать энтропию при анализе;

• Репорты в json;

• Легко задавать исключения;

• В пилоте показал лучший результат.

Как он работает — в основе лежит toml файл с описанием правил, например: 

[[rules]]
  description = "generic secret regex"
  regex = '''secret(.{0,20})([0-9a-zA-Z-._{}$/+=]{20,120})'''
  tags = ["secret", "example"]

Кроме того в правиле можно указывать требуемую энтропию, например: 

[[rules]]
  description = "entropy and regex example"
  regex = '''secret(.{0,20})([0-9a-zA-Z-._{}$/+=]{20,120})'''
  [[rules.Entropies]]
    Min = "4.5"
    Max = "4.7"

В переводе на человеческий это означает: «Если мы встречаем строку кода, которая соответствует регулярному выражению, и эта строка попадает в пределы энтропии от 4,5 до 4,7, то это пароль»

Я не буду заниматься переводом документации, все прекрасно описано тут.

Пример срабатывания:

➜  ~  gitleaks --repo=gitleaks --repo=https://github.com/gitleakstest/gronit.git --verbose --pretty
INFO[2020-04-28T13:00:34-04:00] cloning... https://github.com/gitleakstest/gronit.git
Enumerating objects: 135, done.
Total 135 (delta 0), reused 0 (delta 0), pack-reused 135
{
        "line": "const AWS_KEY = "AKIALALEMEL33243OLIAE"",
        "offender": "AKIALALEMEL33243OLIA",
        "commit": "eaeffdc65b4c73ccb67e75d96bd8743be2c85973",
        "repo": "gronit.git",
        "rule": "AWS Manager ID",
        "commitMessage": "remove fake key",
        "author": "Zachary Rice",
        "email": "zricethezav@users.noreply.github.com",
        "file": "main.go",
        "date": "2018-02-04T19:43:28-06:00",
        "tags": "key, AWS"
}
...
...
WARN[2020-04-28T13:00:35-04:00] 6 leaks detected. 33 commits audited in 77 milliseconds 738 microseconds

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

Если произошло ложное срабатывание — достаточно занести строку в whitelist правила, например:

[[rules]]
  description = "entropy and regex example"
  regex = '''secret(.{0,20})['|"]([0-9a-zA-Z-._{}$/+=]{20,120})['|"]'''
  [[rules.Entropies]]
    Min = "4.5"
    Max = "4.7"
  [[rules.whitelist]]
    regex = '''secret.some_value_that_match_regexp_but_not_really_a_secret'''
    description = "ignore that string"

В результате мы пришли к такой схеме — при создании pull request через webhook вызывается Jenkins, который скачивает репозиторий, запускает для него gitleaks и если тот находит утечки — ставит статус NEED WORK.

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

Проверяем ansible

Двигаемся дальше, итак, мы хотим находить вот такие playbook, потому что не хотим случайно засветить в логах Jenkins наши креды.

- name: Deploy
  hosts: all
  tasks:
    - name: Update
      shell: "update.sh --user={{ update_user }} --password={{ update_password }}"

С ansible все просто — его легко распарсить, можно использовать OPA (рекомендую статью от Александра Токарева  по теме), можно самим быстро написать проверки в python.

Хорошо что мы этого не сделали, а вспомнили про Ansible Lint.

Это официальный линтер для Ansible, который имеет «из коробки» кучу полезных проверок, но нас интересует не это.

Нам были нужны вот эти 2 фичи:

• Возможность писать свои правила;

• Автоматическое сканирование и поиск playbook. Не нужно передавать конкретные файлы на проверку, можно запустить линтер в папке и он сам найдет их. 

Писать правила очень просто — правило представляет собой python код, в котором обязательно должны быть объявлены переменные id, short description, description и tags (их использует Ansible Lint для ведения списка правил) и методы match или matchtask, в которых мы пишем саму логику проверки. Более подробно предлагаю почитать в оригинальной документации.

Для нашей проверки мы используем matchtask, на вход которого поступает каждый найденный task, который мы можем анализировать. 

К сожалению я не могу здесь привести код именно нашего таска, но он похож на этот пример (полностью тут):

class CommandsInsteadOfModulesRule(AnsibleLintRule):
    id = '303'
    shortdesc = 'Using command rather than module'
    description = (
        'Executing a command when there is an Ansible module '
        'is generally a bad idea'
    )
    severity = 'HIGH'
    tags = ['command-shell', 'resources', 'ANSIBLE0006']
 
    _commands = ['command', 'shell']
    _modules = {
        'apt-get': 'apt-get',
#сокращаю список, чтобы не постить простыню
        'yum': 'yum',
    }
 
    def matchtask(self, file, task):
        if task['action']['__ansible_module__'] not in self._commands:
            return
 
        first_cmd_arg = get_first_cmd_arg(task)
        if not first_cmd_arg:
            return
 
        executable = os.path.basename(first_cmd_arg)
        if executable in self._modules and 
                boolean(task['action'].get('warn', True)):
            message = '{0} used in place of {1} module'
            return message.format(executable, self._modules[executable])

Логика примерно такая — если task является command или shell и первый аргумент является командой из списка _modules — рекомендуем заменить команду на модуль.

Нашу проверку мы организовали похожим образом — составили список интересующих нас аргументов (password/pass/login итд) и анализируем каждый аргумент тасков command и shell на попадание в список. 

Кроме того мы учитываем атрибут no_log, при его наличии аргументы не анализируем. Если в будущем разработчик уберет no_log — новый код опять попадет на проверку и наше правило это увидит.

Итак, после проверки Gitleaks запускается Ansible Lint, который в режиме автоматического сканирования прогоняет наше правило. Другие правила мы отключили, т.к. не можем навязывать командам использование линтера (хотя и рекомендует всем).

Проверяем withCredentials

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

node {
  stage('Jenkins Credentials | Decrypt Secret File') {
    withCredentials([file(credentialsId: 'credentials-id', variable: 'secretFile')]) {
      sh 'cat $secretFile'
    }
  }
}

А вот тут нас ждал провал.

Jenkinsfile это по сути groovy, который можно разобрать на Abstract Syntax Tree и анализировать.  Мы использовали AstBuilder чтобы получить дерево, научились находить withCredentials, анализировать его параметры и находить их использование внутри withCredentials. Например, код выше мы научились анализировать и реагировать на него.

Однако в жизни все сложнее, например я могу записать secretFile в глобальную переменную и использовать где-то в другом stage, могу записать secretFile в какой то временный файл итп итд. 

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

Кстати, если у вас используется только декларативный pipeline то потенциально можно использовать Pipeline model definition plugin, в котором можно конвертнуть pipeline в удобный json и анализировать уже его. Нам это к сожалению не подошло — у нас вовсю используется скриптовый.

Что в результате?

Мы провели внутренний пилот, в который попало 1000 pull request. Порядка 3% были ложные срабатывания gitleaks, в некоторых случаях были найдены реальные секреты, опасные скрипты ansible.

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

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

• https://nightfall.ai/resources/introducing-radar-api-detect-credentials-secrets-in-code-via-machine-learning/ — обещают интеллектуальный поиск паролей в исходниках. Кто-нибудь пробовал?

• https://www.shellcheck.net/ — поможет найти кучу проблем в shell скриптах.

• https://github.com/PyCQA/bandit — отличный security linter для python.

• https://twitter.com/leak_scavenger — просто интересный бот в твиттер, который сканит github, pastebin, ghostbin на предмет секретов, кредиток, приватных ключей итд. Исходники, конечно, доступны.

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

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

Расширенное приложение операторов поиска Google — Google Dorking — использование операторов поиска для поиска определенных уязвимых устройств с помощью целевых поисковых строк. Если мы предположим, что Google проиндексировал большинство устройств, случайно подключенных к Интернету, мы можем использовать текст, который, как мы знаем, появляется на их страницах входа в систему или административных страницах, чтобы найти их.

Что понадобится?

Для этого вам понадобится браузер с доступом в Интернет. Всё.

Прекрасной особенностью использования Google dorks является то, что мы можем использовать инструменты, доступные почти каждому, для поиска уязвимых систем

Когда у вас откроется браузер, перейдите на Google.com, и мы сможем начать.

Поиск FTP-серверов и веб-сайтов с использованием HTTP

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

Поиск этих серверов может позволить нам найти файлы, которые должны быть внутренними, но по незнанию были обнародованы.

intitle:"index of" inurl:ftp after:2018

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

Сканирование Google приводит к полному списку всех файлов, содержащихся на сервере.

Если мы хотим найти небезопасные веб-страницы, по-прежнему использующие HTTP для поиска, мы можем слегка изменить команду, изменив «ftp» на «http» и повторно выполнив запрос.

intitle:"index of" inurl:http after:2018

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

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

intitle:"forum" inurl:http after:2018

Мы можем продолжать добавлять поисковые операторы, такие как AND inurl: «registration», чтобы получить более конкретную информацию и искать страницы регистрации незащищенных веб-сайтов.

Находим логи с паролями

Следующим шагом будет поиск файлов типа .LOG.

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

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

allintext:password filetype:log after:2018

При поиске текущих файлов журналов, мы находим это практически сразу.

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

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

Ищем файлы конфигурации с паролями

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

Если мы ищем файлы .ENV, которые содержат строку для пароля базы данных, мы немедленно находим пароль для этой базы данных, которую мы обнаружили.

filetype:env "DB_PASSWORD" after:2018

Если мы удалим after: 2018, мы увидим старые файлы, которые также предоставляют открытый доступ.

Как насчет почты?

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

Эти списки часто выставляются компаниями или школами, которые пытаются составить списки адресов электронной почты для своих людей.

Чтобы найти такие почты, мы будем искать тип файла .XLS электронной таблицы со строкой «email.xls» в URL.

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

Камеры!

Если вы думали, что Shodan был единственным сервисом, который может найти открытые камеры, то вы очень сильно ошибаетесь.

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

Одним из распространенных форматов поиска строк веб-камеры является «top.htm» в URL с указанием текущего времени и даты.

inurl:top.htm inurl:currenttime

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

inurl:"lvappl.htm"

С помощью этого, я смог найти лучшую камеру из всех — птичью!

Многие камеры также контролируют зоны внутри заводов или промышленных территорий.

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

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

Google Dorks дает возможность взламывать открытые сервисы

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

Взлом сайта — неприятная штука, но рано или поздно это может произойти с вашим сайтом. По данным сервиса Internet Live Stats в 2018 году около 100.000 сайтов взламывалось ежедневно, поэтому к этому событию лучше подготовиться заранее, и знать, что следует делать, если это произойдет.

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

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

Содержание:

Как хакеры взламывают сайты
Журнал событий сервера

• Как читать логи сервера
• Как найти нужные данные
• Как отсеять обычных посетителей

Устраните уязвимость
Автоматизируйте процесс

Как хакеры взламывают сайты

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

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

Основные способы, которыми хакеры проникают на сайты:

• Перебор паролей (взлом грубой силой) — Хакер просто пытается угадать ваш логин и пароль. Если вы используете простые логины, например, Admin или Administrator, это дает хакерам половину данных для доступа к вашему сайту. Если вы используете простые пароли, то это еще более ускоряет проникновение на ваш сайт.
• Уязвимости софта — Когда хакеры определяют, что вы используете устаревший софт, по спискам известных уязвимостей, находящимся в открытом доступе, они находят уязвимость в вашей устаревшей версии Вордпресс, плагина, темы или скрипта, и, например, внедряют свой скрипт для проникновения на ваш сайт.
• Бэкдоры — Хакер внедряет файл в файловую структуру сайта. В файле находится скрипт, который позволяет хакеру получить доступ к сайту, оставаясь при этом незамеченным. Бэкдоры.
• Небезопасный сервер — Сервер, на котором расположен ваш сайт, должен быть безопасным. Если он небезопасен, хакеры могут использовать уязвимости в ПО сервера для проникновения на ваш сайт.
• Неверные права доступа — Права доступа к файлам и папкам определяют, кто может читать, записывать и исполнять файлы. Если вы установите слишком низкие права доступа, хакеры смогут редактировать ваши файлы, внедрять скрипты, например, бэкдоры, и в итоге получат контроль над сайтом.
• XML-RPC эксплоиты — XML-RPC используется для трекбэков и пингбэков. Это позволяет делать несколько удаленных вызовов по одному HTTP запросу. Например, сайт может отправлять пингбеки на другие сайты и получать их от других сайтов. Проблема в том, что хакеры могут использовать эту функцию для выполнения удаленных автоматических атак с перебором паролей, когда они без ограничения с высокой частотой перебирают разные варианты логина и пароля. Подробнее.
• Вредоносное ПО и вирусы — Если у вас на компьютере есть вредоносное ПО или вирусы, хакеры могут их использовать для проникновения на сайт.
• Фишинг — Хакеры могут захватить или создать похожий на оригинальный сайт. На захваченном или похожем сайте хакеры создают похожую на оригинальную форму авторизации, чтобы похитить персональные данные пользователей, когда они авторизуются на сайте.
• XSS-атаки (Cross-site Scripting) — Это код, написанный определенным образом, который позволяет хакеру записывать и выполнять вредоносный JavaScript, который сохраняет данные браузера пользователя. Хакеры отправляют ссылку пользователям сайта, чтобы похитить любую информацию, введенную пользователями при просмотре сайта.
• CSRF (Cross-site request forgery) — Подделка межсайтового запроса. Хакер вносит изменение в оригинальный запрос пользователя, создавая свой вредоносный запрос. У хакера нет прав администратора, поэтому он обманным путем заставляет пользователя совершать действия, которые дают хакеру разрешение на выполнение этого вредоносного запроса. Такой тип атак используется для того, чтобы заставить пользователя делать нужные действия, например, предоставить свои логин и пароль для входа на сайт.

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

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

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

Журнал событий сервера

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

Логи находятся на хостинг панели, в зависимости от используемого софта они могут называться по-разному: «Логи», «Журнал событий», «Метрики» или что-нибудь в этом роде. Обычно в этом разделе находятся 2 журнала: «Логи ошибок» и «Логи доступа». Лог ошибок сервера короче, поэтому начать можно с них, но они не показывают успешные попытки доступа.

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

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

Сохраните файлы на компьютер из хостинг панели или напрямую с сервера, и откройте в любой текстовой программе, например Notepad++ или Brackets.

Как читать логи сервера

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

Структура записи в Журнале ошибок:

• Дата и время
• Тип ошибки
• IP адрес пользователя
• Описание ошибки
• Путь к файлу страницы, на которой произошла ошибка
• URL сайта, с которого пользователь пришел на страницу с ошибкой

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

Логи событий тоже имеют стандартную структуру:

• IP адрес пользователя
• Дата и время
• Используемый HTTP метод и версия
• HTTP код ответа
• Количество полученных байтов
• Используемый софт (браузер или ОС посетителя)
• User agent

Как найти нужные данные

Начните с просмотра Лога ошибок, это может дать подсказку для поиска взлома в Логах доступа.

Если вы увидели, что кто-то пытался получить доступ к файлам, которые обычный посетитель не должен посещать, но хакер может, тогда обратите внимание на этот IP. Хакер может попытаться получить доступ к файлам .htaccess, wp-config.php, install.php и другим подобным.

Пример ошибки в Логе ошибок:

[Sat Jul 07 16:17:46 2018] [error] [client 123.45.67.890:20744] AH01630: client denied by server configuration: /путь/к/вашему/сайту/.htaccess

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

Если вы не знаете свой IP адрес, узнайте его здесь, или спросите в поисковике «мой IP адрес».

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

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

В этом примере вы видите, что пользователь обратился к странице ~/wp-login.php в первой строке, и запрос был успешным.

После того, как загрузились все нужные файлы, пользователь был успешно авторизован и направлен на страницу Консоли в строке 5. Следующим действием администратор прошел в редактор плагинов в строке 9.

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

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

Большое количество неудачных попыток войти на сайт перед последней удачной попыткой будут иметь один из 400-х ответов сервера:

• 400 Bad Request — Ошибка синтаксиса или неверный запрос.
• 401 Unauthorized — Эта ошибка появляется, когда требуется авторизация для просмотра страницы, но она не была дана, или она недействительна.
• 403 Forbidden — аналогично с ошибкой 401, этот ответ означает, что пользователь не имеет прав для просмотра этой страницы. То есть, технически доступ разрешен, но сервер запретил доступ этому пользователю.
• 429 Too Many Requests — Слишком много запросов за определенный период времени. Обычно пользователи не видят такой ответ, такая ошибка может указывать на активность какого-то бота.

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

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

Как отсеять обычных посетителей

Чтобы уменьшить количество информации в логе можно отфильтровать обычные запросы. Откройте SSH клиент, например, Terminal для MacOS или PuTTY для Windows, или встроенный SSH клиент на хостинге, и попробуйте отсеять безопасные запросы.

С помощью этих команд вы можете отсеять 2/3 записей, в которых запрашивались картинки, файлы скриптов и стилей, главная страница, страница контактов и страница регистрации на сайте.

$ cat access-log |grep -Ev «.(js|css|png|jpg|jpeg) HTTP/1″ |grep -Ev » GET (/|/contact|/signup) HTTP/1″| more

Главная страница обозначена / в части GET (/|/contact|/signup). Вы также можете изменить contact и signup на другие страницы, или добавить другие страницы.

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

$ cat access-log |grep -E «wp-admin|wp-login|POST /» | more

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

Если вы знаете IP адреса админов, редакторов и других ролей, вы можете исключить эти запросы с помощью этой команды:

$ cat access-log |grep -E «wp-admin|wp-login|POST /» |grep -v «^1.2.3.4|1.2.3.5» | more

Замените 1.2.3.4 и 1.2.3.5 на свои адреса.

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

Устраните уязвимость

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

Автоматизируйте процесс

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

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

Читайте также:

1. Как проверить и вылечить от вирусов Вордпресс сайт
2. 2 Примера взлома и лечения сайта
3. Как очистить сайт от вирусов и удалить его из черных списков
4. Как зайти в Консоль Вордпресс после взлома сайта

Надеюсь, статья была полезна. Оставляйте комментарии.