- Гостевая статья Как очистить записи и журналы в Linux
- Заметаем следы вместе с хакерами. Чистим логи и историю Bash на взломанных Linux системах
- Шаг 1. Скомпрометируйте цель
- Шаг 2. Создайте легко удаляемый скрытый каталог
- Шаг 3. Удалите историю Bash
- Шаг4. Очистите файлы журнала
- Шаг 5. Используйте специальный инструмент для наилучшего сокрытия следов
- Заключение
- Как очистить (усечь) файлы журнала в Linux
- Как очистить (усечь) файлы журнала в Linux
- Пустой файл журнала с помощью команды truncate
- Пустой файл журнала, используя:> или true>
- Пустой файл журнала с помощью команды echo
- Пустой файл журнала с помощью команды dd
- Использование journalctl для просмотра и анализа логов: подробный гайд
- Systemd
- Journald
- Файл конфигурации journald
- Использование journalctl для просмотра и анализа логов
- Фильтрация событий по важности
- Настройка хранения журналов
- Просмотр журналов загрузки
- Просмотр журнала за определенный период времени
- Просмотр сообщений ядра
- Просмотр журнала логов для определенного сервиса systemd или приложения
- Дополнительные опции просмотра
- Ограничение размера журнала
- Удаление журналов
- Заключение
Гостевая статья Как очистить записи и журналы в Linux
Почему это важно?
Сокрытие записей является заключительным этапом процесса тестирования проникновения перед написанием отчета. Он предполагает очистку или стирание всей активности злоумышленника, чтобы избежать обнаружения.
Так что это жизненно важно в цикле тестирования проникновения, теперь с оборонительной точки зрения это действительно может проверить обработчики инцидентов и синяя команда и проверить их способность обнаружить нападающего и найти все, что нападающий, возможно, забыл очистить.
Это, как правило, самый большой вектор ошибки нападающего и именно там профессионалы отсортированы от любителей.
С точки зрения злоумышленников, он/она должен уклоняться от обнаружения с помощью IDS, тем самым предотвращая любые действия по реагированию на инциденты, и должен очищать любые журналы или бэкдоры, которые могут быть обнаружены группой судебно-медицинской экспертизы.
Что атакующий будет и должен делать
- Очистить логи
- Изменить реестр или очистить
- Удаление любых файлов, которые вы создали
Я собираюсь рассмотреть основные принципы, но в большей степени для Linux систем, так как именно здесь мои знания и опыт.
Очистка ваших записей также будет зависеть от привилегий, которые вы имеете в системе (если вы атакуете ее удаленно).
Файлы журнала хранятся в каталоге /var/log
— Редактирование файлов будет действительно не легким, я бы рекомендовал использовать инструмент под названием shred для удаления или изменения файла.
Что такое Shreed
Shreed — это инструмент, позволяющий удалить файл или данные навсегда и препятствующий восстановлению данных, поскольку он несколько раз перезаписывает файл с помощью 1 s и 0s (при удалении файла на компьютере он действительно не удаляется, он просто помечается как пространство, в которое можно записать данные)
Shred очень популярен при стирании жестких дисков и т.д., я использовал его много раз, прежде чем удалить или продать мои диски.
Параметры при использовании команды Shred
Команда Shred используется для повторной перезаписи указанных файлов, что затрудняет или делает невозможным восстановление данных даже дорогостоящим оборудованием или программным обеспечением. Доступные параметры включают:
- -f изменяет разрешения, чтобы разрешить запись при необходимости
- -n (iterations = N) перезаписывает N раз вместо значения по умолчанию, которое составляет три раза
- -s (размер = N) указывает количество байтов для уничтожения
- -u обрезает и удаляет файлы после перезаписи
- -v показывает подробную информацию о прогрессе
- -x не округляет размеры файлов до следующего полного блока
- -z добавляет окончательную замену нулями, чтобы скрыть измельчение
- -u удаляет файл после перезаписи
Общие файлы журналов и какие данные они содержат
/var/log/auth.log: логи аутентификации
/var/log/kern.log: логи ядра
/var/log/cron.log: журналы Crond (задание cron)
/ var / log / maillog: журналы почтового сервера
/ var / log / httpd /: каталог доступа и журналов ошибок Apache
/var/log/boot.log: журнал загрузки системы
Чтобы стереть файл:
Shred -vfzu auth.log
История bash сохраняет запись всех команд, выполняемых пользователем в командной строке Linux.
Источник
Заметаем следы вместе с хакерами. Чистим логи и историю Bash на взломанных Linux системах
Последним этапом деятельности любого хакера является заметание следов.
Автор: DRD_, Cyber Weapons Lab
Последним этапом деятельности любого хакера является заметание следов. Киберпреступник удаляет следы своей деятельности и логи, чтобы избежать обнаружения. Данный этап особенно важен, если злоумышленник в будущем планирует снова получить доступ к целевому устройству.
Для демонстрации основ заметания следов, сначала скомпрометируем цель, а затем изучим несколько методов, используемых для удаления истории Bash и очистки логов после взлома Linux систем.
Шаг 1. Скомпрометируйте цель
Первое, что нам следует сделать, — взломать цель. Используя некорректную обработку сервером команд ОС, можно применить внедрение команд, для получения оболочки. Затем нашу новую оболочку необходимо обновить до полностью интерактивной. Данная процедура значительно упростит работу. После этого мы сможем повысить наши привилегии до root, чтобы наилучшим образом использовать преимущества системы и оставаться незамеченными.
Шаг 2. Создайте легко удаляемый скрытый каталог
Получив root-доступ, мы можем создать скрытый каталог для работы и хранить в нем любые скрипты или файлы. С одной стороны, подобные манипуляции обманут лишь самого начинающего администратора, но дополнительный уровень защиты определенно не повредит. Во-первых, давайте найдем все доступные для записи каталоги с помощью следующей команды:
С помощью команды mkdir можно создать скрытый каталог, добавив точку к имени:
Зададим команду перечисления содержимого /dev/shm. Как видим, ничего не появилось:
Каталог появляется лишь тогда, когда мы используем переключатель -a для вывода списка всех файлов и каталогов:
Для удаления каталога после завершения работы на машине, используйте команду rmdir :
Шаг 3. Удалите историю Bash
Команды записываются в переменную среды HISTFILE, обычно это .bash_history. Воспользуемся echo для определения местоположения:
Используем команду unset для удаления переменной:
Повторив процедуру снова, видим, что ничего не появляется:
Чтобы история команд не сохранялась, также можно ее отправить в /dev/null. Для этого установите переменную:
Или сделайте то же самое с командой экспорта:
История теперь будет отправлена в /dev/null (то есть никуда):
Установите количество команд, которые будут сохраняться во время текущего сеанса, равным 0, используя переменную HISTSIZE:
В качестве альтернативы используйте команду экспорта:
Измените количество строк, разрешенных в файле истории, с помощью переменной HISTFILESIZE. Установите данное значение на 0:
Или с экспортом:
Для изменения параметров оболочки также можно использовать команду set. Чтобы отключить опцию истории, используйте следующую команду:
Снова включите ее:
Точно так же для изменения параметров оболочки можно использовать команду shopt. Чтобы отключить историю, используйте следующую команду:
Снова включите ее:
Во время выполнения команд на целевой системе иногда получается избежать их сохранения в истории, запустив команду с начального пробела:
Данный метод работает не всегда и зависит от системы. Также можно просто очистить историю с помощью переключателя -c :
Чтобы убедиться, что изменения записаны на диск, используйте переключатель -w :
Данные действия очистят историю только для текущего сеанса. Чтобы окончательно убедиться, что история очищается при выходе из сеанса, пригодится следующая команда:
Также можно использовать команду kill для выхода из сеанса без сохранения истории:
Шаг4. Очистите файлы журнала
Конечно, можно просто удалить журнал с помощью команды rm :
Но скорее всего, данная процедура вызовет многочисленные красные флажки. Поэтому лучше сделать файл пустым, чем стирать его полностью. Используем команду truncate, чтобы уменьшить размер файла до 0:
Обратите внимание, функция усечения присутствует не всегда и не во всех системах.
То же самое можно сделать, отображая в файл “ничего”:
А также использовать > сам по себе для очистки файла:
Мы также можем отправить его в /dev/null:
Или использовать команду tee :
Также можно использовать команду dd, чтобы ничего не записывать в файл журнала:
Команда shred может быть использована, чтобы поверх перезаписать файл с бессмысленными двоичными данными:
Дополнительно добавив -zu, вы обрежете файл и перезапишете его нулями:
Шаг 5. Используйте специальный инструмент для наилучшего сокрытия следов
Перейдите в каталог с возможностью записи и используйте chmod, чтобы сделать его исполняемым:
Затем запустите его:
Нам предоставляется настраиваемая подсказка с несколькими вариантами на выбор. Выберем первый, чтобы очистить логи:
Также можно отключить Bash и историю авторизации с помощью опции 2:
Если вам нужно срочно все очистить, просто добавьте в команду now:
Заключение
Отмечу, что существуют и другие способы удаления следов атаки. Можно использовать Metasploit , сценарии оболочки или осуществить сокрытие следов на взломанной Windows системе. Тем не менее информации, приведенной в статье, вполне достаточно для сокрытия активности на базовом Linux компьютере.
Источник
Как очистить (усечь) файлы журнала в Linux
Как очистить (усечь) файлы журнала в Linux
В какой-то момент жизненного цикла Sysadmin может потребоваться очистить файл журнала, чтобы сэкономить место на системном диске или по любой другой причине. Существуют различные способы очистки файла в системе Linux.
Пустой файл журнала с помощью команды truncate
Самый безопасный способ очистки файла журнала в Linux — использование команды truncate. Команда усечения используется для сокращения или расширения размера каждого ФАЙЛА до указанного размера.
Где -s используется для установки или настройки размера файла по размеру байтов. file Может быть относительно текущего каталога или абсолютный путь к файлу при условии.
Для полных опций команды усечения используйте опцию —help
Пустой файл журнала, используя:> или true>
Вы также можете использовать :> для очистки содержимого файла. Синтаксис
Пустой файл журнала с помощью команды echo
Если вы ничего не отобразите в файле, он очистит содержимое, чтобы очистить его.
Пустой файл журнала с помощью команды dd
Синтаксис для использования dd команды
Смотрите примеры ниже
Для нескольких файлов достаточно простого цикла в bash.
Используйте любой из методов, чтобы очистить ваши большие файлы журнала.
Источник
Использование journalctl для просмотра и анализа логов: подробный гайд
Journalctl — отличный инструмент для анализа логов, обычно один из первых с которым знакомятся начинающие администраторы linux систем. Встроенные возможности ротации, богатые возможности фильтрации и возможность просматривать логи всех systemd unit-сервисов одним инструментом очень удобны и заметно облегчают работу системным администраторам.
Эта статья рассматривает основные возможности утилиты journalctl и различные варианты ее применения. С помощью journalctl можно просматривать логи системы, чтобы решить возникшие проблемы на рабочей станции или сервере использующие дистрибутив linux с демоном инициализации systemd, де-факто уже ставшим стандартом в современных Linux-системах, например: RHEL, CentOS, Fedora, Debian и многих других.
Существует мнение, что systemd не так уж и хорош — он нагружает систему и это все еще предмет для споров на сегодняшний день, но нельзя отрицать, что он предоставляет прекрасный набор инструментов для управления системой и поиска проблем. Представьте, что вам приходится иметь дело с проблемным сервером, который даже не загружается — в таком случае можно загрузиться с live-дистрибутива, смонтировать системный раздел и просмотреть логи systemd, чтобы понять, в чем проблема.
Systemd
Systemd состоит из трех основных компонентов:
- systemd — менеджер системы и сервисов
- systemctl — утилита для просмотра и управление статусом сервисов
- systemd-analyze — предоставляет статистику по процессу загрузки системы, проверяет корректность unit-файлов и так же имеет возможности отладки systemd
Journald
Journald — системный демон журналов systemd. Systemd спроектирован так, чтобы централизованно управлять системными логами от процессов, приложений и т.д. Все такие события обрабатываются демоном journald, он собирает логи со всей системы и сохраняет их в бинарных файлах.
Преимуществ централизованного логирования событий в бинарном формате достаточно много, например системные логи можно транслировать в различные форматы, такие как простой текст, или в JSON, при необходимости. Так же довольно просто можно отследить лог вплоть до одиночного события используя фильтры даты и времени.
Файлы логов journald могут собирать тысячи событий и они обновляются с каждым новым событием, поэтому если ваша Linux-система работает достаточно долго — размер файлов с логами может достигать несколько гигабайт и более. Поэтому анализ таких логов может происходить с задержками, в таком случае, при анализе логов можно фильтровать вывод, чтобы ускорить работу.
Файл конфигурации journald
Файл конфигурации можно найти по следующему пути: /etc/systemd/journald.conf, он содержит различные настройки journald, я бы не рекомендовал изменять этот файл, если вы точно не уверены в том, что делаете.
Каталог с журналом journald располагается /run/log/journal (в том случае, если не настроено постоянное хранение журналов, но об этом позже).
Файлы хранятся в бинарном формате, поэтому нормально их просмотреть с помощью cat или nano, как привыкли многие администраторы — не получится.
Использование journalctl для просмотра и анализа логов
Основная команда для просмотра:
Она выведет все записи из всех журналов, включая ошибки и предупреждения, начиная с того момента, когда система начала загружаться. Старые записи событий будут наверху, более новые — внизу, вы можете использовать PageUp и PageDown чтобы перемещаться по списку, Enter — чтобы пролистывать журнал построчно и Q — чтобы выйти.
По умолчанию journalctl выводит время событий согласно настроенного в вашей системе часового пояса, также journalctl позволяет просмотреть логи с временем UTC (в этом стандарте времени сохраняются события внутри файлов journald), для этого можно использовать команду:
Фильтрация событий по важности
Система записывает события с различными уровнями важности, какие-то события могут быть предупреждением, которое можно проигнорировать, какие-то могут быть критическими ошибками. Если мы хотим просмотреть только ошибки, игнорируя другие сообщения, введем команду с указанием кода важности:
# journalctl -p 0
Для уровней важности, приняты следующие обозначения:
- 0: emergency (неработоспособность системы)
- 1: alerts (предупреждения, требующие немедленного вмешательства)
- 2: critical (критическое состояние)
- 3: errors (ошибки)
- 4: warning (предупреждения)
- 5: notice (уведомления)
- 6: info (информационные сообщения)
- 7: debug (отладочные сообщения)
Когда вы указываете код важности, journalctl выведет все сообщения с этим кодом и выше. Например если мы укажем опцию -p 2, journalctl покажет все сообщения с уровнями 2, 1 и 0.
Настройка хранения журналов
По умолчанию journald перезаписывает свои журналы логов при каждой перезагрузке, и вызов journalctl выведет журнал логов начиная с текущей загрузки системы.
Если необходимо настроить постоянное сохранение логов, потребуется отдельно это настроить, т.к. разработчики отказались от постоянного хранения всех журналов, чтобы не дублировать rsyslog.
Когда в конфигурационном файле /etc/systemd/journald.conf параметру Storage= задано значение auto) и каталога /var/log/journal/ не существует, журнал будет записываться в /run/log/journal без сохранения между перезагрузками, если /var/log/journal/ существует, журналы будут сохраняться в нем, на постоянной основе, но если каталог будет удален, systemd не пересоздаст его автоматически и вместо этого будет вести журнал снова в /run/systemd/journal без сохранения. Каталог может быть пересоздан в таком случае, если добавить Storage=persistent в journald.conf и перезапустить systemd-journald.service (или перезагрузиться).
Создадим каталог для хранения журналов, установим необходимые атрибуты и перезапустим службу:
Просмотр журналов загрузки
Если journald был настроен на постоянное хранение журналов, мы можем просматривать журналы логов по каждой отдельной загрузке, следующая команда выведет список журналов:
Первый номер показывает номер журнала, который можно использовать для просмотра журнала определенной сессии. Второй номер boot ID так же можно использовать для просмотра отдельного журнала.
Следующие две даты, промежуток времени в течении которого в него записывались логи, это удобно если вы хотите найти логи за определенный период.
Например, чтобы просмотреть журнал начиная с текущего старта системы, можно использовать команду:
А для того, чтобы просмотреть журнал предыдущей загрузки:
Просмотр журнала за определенный период времени
Journalctl позволяет использовать такие служебные слова как “yesterday” (вчера), “today” (сегодня), “tomorrow” (завтра), или “now” (сейчас).
Поэтому мы можем использовать опцию «—since» (с начала какого периода выводить журнал).
С определенной даты и времени:
С определенной даты и по определенное дату и время:
Со вчерашнего дня:
С 9 утра и до момента, час назад:
Просмотр сообщений ядра
Чтобы просмотреть сообщения от ядра Linux за текущую загрузку, используйте команду с ключом -k:
Просмотр журнала логов для определенного сервиса systemd или приложения
Вы можете отфильтровать логи по определенному сервису systemd. Например, что бы просмотреть логи от NetworkManager, можно использовать следующую команду:
Если нужно найти название сервиса, используйте команду:
Так же можно просмотреть лог приложения, указав его исполняемый файл, например чтобы просмотреть все сообщения от nginx за сегодня, мы можем использовать команду:
Или указав конкретный PID:
Дополнительные опции просмотра
Следить за появлением новых сообщений (аналог tail -f):
Открыть журнал «перемотав» его к последней записи:
Если в каталоге с журналами очень много данных, то фильтрация вывода journalctl может занять некоторое время, процесс можно значительно ускорить с помощью опции —file, указав journalctl только нужный нам журнал, за которым мы хотим следить:
По умолчанию journalctl отсекает части строк, которые не вписываются в экран по ширине, хотя иногда перенос строк может оказаться более предпочтительным. Управление этой возможностью производится посредством переменной окружения SYSTEMD_LESS, в которой содержатся опции, передаваемые в less (программу постраничного просмотра, используемую по умолчанию). По умолчанию переменная имеет значение FRSXMK, если убрать опцию S, строки не будут обрезаться.
Ограничение размера журнала
Если journald настроен что бы сохранять журналы после перезагрузки, то по умолчанию размер журнала ограничен 10% от объема файлового раздела и максимально может занять 4 Гб дискового пространства.
Максимальный объем журнала можно скорректировать, раскомментировав и отредактировав следующий параметр в файле конфигурации journald:
Удаление журналов
Удалить файлы архивных журналов, можно вручную с помощью rm или использовав journalctl.
Удалить журналы, оставив только последние 100 Мб:
Удалить журналы, оставив журналы только за последние 7 дней:
Заключение
Служба журналирования логов journald очень мощный и гибкий инструмент, и если вы знаете как его использовать, он может сделать вашу жизнь намного проще во время поиска причин проблем с системой или ее сервисами.
Источник