Telegram аудит логов в linux

Содержание

Еще по теме: Заблокировать Телеграмм на планшете

Приветствую читателей своего сайта. Сегодня я всесторонне рассмотрю тему тему логов в Ubuntu — ошибки, загрузка, системные логи, cron и остальное. Постараюсь дать обзорную информацию по основным моментам в этой теме. Материал в основном рассчитан на новичков, но возможно восполнит пробелы и специалистов.

Основные log файлы Ubuntu

Традиционно логи в Linux хранятся в директории /var/log . Вот описание стандартных лог файлов Ubuntu, которые там присутствуют. Кстати, если вы только планируете устанавливать ubuntu, то можете воспользоваться моей подробной статьей на этот счет — установка ubuntu server. Так же вам может быть интересен мой обзор и сравнение сервера убунту с другими linux системами — Ubuntu Server — обзор для начинающих, сравнение, отзывы.

syslog или messages. Последнего чаще всего нет и вместо него только syslog. Это традиционные глобальные системные журналы операционной системы linux. Сюда пишутся события загрузки, ядра системы, системы инициализации systemd и т.д.
auth.log — лог авторизации и аутентификации в системе.
dmesg — в этом логе хранится информация о загрузке ядра и драйверов оборудования.
alternatives.log — лог файл программы update-alternatives. Не знаю, за какие такие заслуги ей выделили отдельный лог файл, а cron, к примеру, нет.
kern.log — лог сообщений ядра ubuntu, да и любой другой linux системы.
maillog — сообщения почтовой системы. Обычно postfix или exim. Если на сервере ubuntu они не установлены, то и почтового лога не будет.
dpkg.log — логирование работы пакетных менеджеров ubuntu. Обычно это apt или apt-get.
lastlog и wtmp — информация о прошлых авторизациях пользователей.

Лог загрузки

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

Логи Linux. Всё о логах и журналировании

sudo dmesg

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

sudo dmesg | grep sda

Вы увидите лог загрузки системы ubuntu, содержащий информацию только о диске sda. Аналогичным образом можно фильтровать вывод по другим темам. Например, посмотреть все ошибки, которые были во время загрузки.

sudo dmesg | grep error

И так далее. Информация, которую выводит команда dmesg, хранится в log файле /var/log/dmesg .

Логи авторизации, в том числе ssh

Для того, чтобы узнать, кто и когда проходил авторизацию на сервере ubuntu, можно воспользоваться логами из файла /var/log/auth.log . Авторизация по ssh там будет выглядеть следующим образом.

sshd[2774]: Accepted publickey for root from 21.17.214.129 port 2673 ssh2: RSA SHA256:MCDja9Ve7rYZCzeVGpYXpqRxfAanWwVkcd+lU3GS sshd[2774]: pam_unix(sshd:session): session opened for user root by (uid=0) systemd-logind[628]: New session 6 of user root.

Здесь мы видим ip адрес, с которого произошло подключение и слепок сертификата, так как аутентификация была произведена с его помощью. Если хотите повысить уровень логирования подключений по ssh и получать больше информации, то можете отредактировать конфигурационный файл sshd — /etc/ssh/sshd_config , добавив туда следующий параметр.

LogLevel VERBOSE

Не забудьте перезапустить службу sshd для принятия изменений:

sudo systemctl restart sshd

После этого логирование подключений по ssh будет более подробное.

Лог локального входа в ubuntu тоже хранится в файле auth.log . Информация о подключении через консоль выглядит следующим образом.

login[680]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) systemd-logind[628]: New session 9 of user root. login[3094]: ROOT LOGIN on ‘/dev/tty1’

Еще по теме: Distortion bot Telegram не работает

Устройство /dev/tty1 говорит о том, что вход локальный.

Вы можете быстро посмотреть информацию о последних входах в систему с помощью команды last. Эта информация хранится в бинарном логе /var/log/lastlog .

Примерно то же самое можно увидеть с помощью utmpdump.

sudo utmpdump /var/log/wtmp

Логи ошибок в Ubuntu

Рассмотрим теперь вопрос с расположением лога ошибок в Ubuntu. Как такового отдельного error log в традиционных linux системах нет. И Убунта тут не исключение. Ошибки придется искать по системным и программным логам выборкой ключевых слов. Обычно используют следующие фразы:

error или err
critical или crit
debug
warn

Например, посмотрим в логе загрузки dmesg все сообщения уровня предупреждений (warn).

sudo dmesg -l warn

А теперь проверим ошибки в системном логе.

sudo cat /var/log/syslog | grep error

Видим некоторые ошибки в службе systemd-resolved.

Cron logs

Часто хочется проверить лог запуска периодических заданий cron. В Ubuntu, как мне кажется, сделали не удобно. По умолчанию, cron logs не выделены в отдельный файл. Искать их стоит в общем системном логе syslog. Например, в Centos существует отдельный лог-файл /var/log/cron, где собрана вся информация о запущенных заданиях. Предлагаю сделать так же в Ubuntu.

Для этого открываем конфигурационный файл /etc/rsyslog.d/50-default.conf и добавляем туда следующую информацию.

cron.* /var/log/cron.log

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

*.*;auth,authpriv.none,cron.none -/var/log/syslog

Я добавил в нее cron.none, чтобы логи cron не писались больше в системный лог syslog. После этого перезапустите службы rsyslog и cron и проверяйте изменения.

sudo systemctl restart rsyslog sudo systemctl restart cron
sudo cat /var/log/cron.log

Теперь у нас все логи Cron в Ubuntu будут в отдельном файле.

Лог действий пользователя

Мне часто задают вопросы, как посмотреть лог действий пользователя в системе или как узнать, какие программы он запускал. По умолчанию, такие действия не логируются в ubuntu. Для этого нужно устанавливать какое-то дополнительное программное обеспечение. Я даже не знаю, кто умеет это делать. Обычно если надо фиксировать действия пользователя, включается лог работы sudo.

Для того, чтобы включить логирование действий пользователя через sudo, редактируем файл /etc/sudoers . Добавляем туда строку.

Defaults logfile=/var/log/sudo.log

Теперь выполните какую-нибудь команду через sudo.

sudo cat /var/log/cron.log
Nov 25 23:10:36 : root : TTY=pts/3 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/cat /var/log/cron.log

Выполненная команда пользователя сохранена в логе sudo.log. Теперь никто не сможет выполнить незаметно административные действия на сервере. Конечно, человек с полными правами сможет изменить любой лог файл, удалив свои действия при желании. Для этого важные логи нужно отправлять куда-то в другое место, но это уже тема отдельной статьи.

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

Один отзыв для “ Основные log файлы в Ubuntu — загрузка, авторизация, ошибки и др. ”

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

Источник: ubuntu-admin.ru

Сбор и анализ логов в Linux

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

В этой статье мы будем говорить о том, как устроено логирование событий в ОС Linux. В качестве примера будет рассматриваться Ubuntu Linux 22.04, однако в других дистрибутивах основные элементы будут сходными.

Локальные логи

В Линуксе журналируются как системные события, так и события от приложений и служб. По умолчанию события журналируются в каталог /var/log/. В нем имеется множество различных *.log файлов содержащих события от различных источников в текстовом виде.

В зависимости от установленных в системе приложений, в каталоге /var/log могут находиться различные файлы журналов. Но мы приведем список основных файлов журналов:

Файлы /var/log/syslog или /var/log/messages – глобальный системный журнал. В нем мы можем найти события, произошедшие с момента запуска системы от различных компонентов ОС – ядра, служб, устройств и т. д.

Журнал событий var/log/kern.log — содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок, произошедших при работе пользовательских модулей встроенных в ядро.

Журналы /var/log/auth.log или /var/log/secure – наиболее интересны для безопасников, так как они содержат информацию об авторизации пользователей, то есть попытки не/успешных входов в систему и методов аутентификации.

События от оборудования и драйверов устройств находятся в файле /var/log/dmesg. В этом файле фиксируются ошибки работы драйверов и оборудования.

События установки системы можно найти в файле /var/log/anaconda.log, а в файле /var/log/boot.log находятся логи загрузки системы.

Еще один журнал событий, который представляет особый интерес для специалистов по информационной безопасности это /var/log/audit — лог демона auditd. Логирование аудита мы еще рассмотрим далее в этой статье.

Журнал демона crond /var/log/cron – содержит результаты выполнения различных событий планировщика задач cron.

Это основные журналы событий, которые есть в большинстве дистрибутивов Linux. Также в зависимости от установленных приложений в /var/log/ могут находиться логи БД MySQL или веб серверов Apache/Nginx.

Что, собственно, пишем

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

Уровни логов или приоритеты определяет ядро Linux. В зависимости от важности события, ему присваивается один из приоритетов, представленных ниже:

KERN_EMERG — система неработоспособна;
KERN_ALERT — нужно немедленно принять меры;
KERN_CRIT — критическая ошибка;
KERN_ERR — обычная ошибка;
KERN_WARNING — предупреждение;
KERN_NOTICE — замечание;
KERN_INFO — информационное сообщение;
KERN_DEBUG — сообщения отладки.

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

Еще одним важным значением в сообщения является категория (Facility). Категории могут принимать значения от 0 до 23, им соответствуют различные категории системных служб: 0

— kernel, 2 — mail, 7 — news и т.д. Последние 8 категорий — от local0 до local7 — определены для служб, не попадающих в предопределённые категории

Локальные недостатки

По умолчанию все журналы событий хранятся на машине локально. Однако даже в небольшой сети такой способ хранения логов не является оптимальным. Для чего нужны журналы событий? Для решения возможных проблем с производительностью, для мониторинга состояния системы и для своевременного выявления подозрительных и вредоносных активностей. И для всех этих активностей лучше использовать централизованное хранение логов на отдельном сервере или хранилище. Дело в том, что на локальных узлах в целях экономии места логи циклически удаляются (ротируются) то есть, при достижении максимального объема файла журнала, самые старые события удаляются. В результате мы можем лишиться важных событий просто потому что они уже затерлись более новыми. Также, не слишком удобно проверять логи локально на каждом узле, централизованно анализировать гораздо проще. Большой поток событий может создавать дополнительную нагрузку на дисковую подсистему.

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

Таким образом, необходимо сохранять основные события со всех узлов на отдельном сервере. Изначально в ОС Linux для этого использовался протокол Syslog, по которому события могли передаваться между серверами. Но этот протокол имеет существенные недостатки. В качестве транспортного протокола Syslog использует UDP, то есть отправка пакетов ведется без подтверждения получения. Таким образом нет никакой гарантии, что отправленное с одного узла событие на сервер Syslog будет доставлено. В случае с критически важными событиями это не очень хорошо.

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

Rsyslog

В качестве альтернативы можно использовать протокол RSyslog (Rocket-fast System for log processing). Преимуществами этого протокола является наличие многопоточности (то есть возможность обрабатывать большой объем событий), использование протокола TCP на транспортном уровне, наличие шифрования SSL, а также возможность сохранения готовых событий в базы данных (MySQL, PostgreSQL, Oracle). Отдельного внимания заслуживает возможность фильтрации по любой части лога и полностью настраиваемый формат вывода событий.

Ниже приводится фрагмент конфига /etc/rsyslog.conf с клиентской машины.

В качестве примера настроим пересылку логов с клиента на сервер. Для этого на стороне сервера необходимо в файле /etc/rsyslog.conf добавить следующие строки:

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

Для того, чтобы не запутаться в собираемых журналах событий лучше всего сразу сохранять пришедши е события в отдельных файлах. Идея складывать все события в один файл очень плоха, так как файлы логов должны, либо подвергаться циклической чистке, когда старые события удаляются, либо архивироваться. И то, и другое ведет к тому, что вы можете потерять часть важных событий. Поэтому лучше использовать следующую структуру /var/log/rsyslog/ИМЯ_УЗЛА_источника/приложение_источник.log . Для этого надо добавить в файл конфигураций следующие строки:

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

Для этого добавим:

Далее перезапускаем службу Rsyslog

systemctl restart rsyslog

На клиенте необходимо настроить пересылку событий на сервер. Для этого нужно создать отдельный файл конфигураций:

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

В примере мы пересылаем все события с клиента на порт 514 сервера 192.168.222.135.

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

Далее также перезапускаем Rsyslog

systemctl restart rsyslog

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

Модули Rsyslog

Иногда возникает необходимость в более интеллектуальной обработке журналов событий, поступающих с источников. Для этого в Rsyslog имеются модули. Модули ввода — начинаются с im, собирают информацию из различных источников. Модули вывода — начинаются на om, и они отправляют сообщения. Могут отправлять сообщения как в файл так и по сети или складывать в базу. Модули фильтрации — начинаются с fm. Фильтруют сообщения по разным параметрам. Модули парсинга — начинаются с pm. Позволяют проводить синтаксический анализ. Модули модификации сообщений — начинаются с mm. Меняют содержимое обрабатываемых сообщений. Модули генерации строк — начинаются с sm. Позволяют генерировать строки на основе обрабатываемых сообщений.

Посмотрим пример для того, чтобы было понятно, о чем идет речь. В следующем примере мы будем на клиенте отслеживать изменения в файле audit.log и отправлять на сервер события с уровнем warning и выше и категорией local0.

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

$template HostAudit, «/var/log/rsyslog/%HOSTNAME%/audit.log»

Сохранение в БД

Собранные события удобно хранить в текстовых файлах лишь когда их не более десятка. При большем объем лучше использовать СУБД для централизованного хранения и обработки событий. В качестве примера будем отправлять все события в MySQL. Вот общий формат таких настроек:

В случае использования PostgreSQL формат будет следующий:

Использование СУБД позволяет не только собирать и хранить события, но и делать запросы по наличию тех или иных событий, строить отчеты и реагировать на появление определенных событий. Хотя, когда количество источников начинает измеряться сотнями, для работы с событиями уже лучше использовать специализированные решения. Например, для обработки событий ИБ лучше использовать решения класса SIEM (Security Information Event Management).

Заключение

В этой статье были рассмотрены основы журналирования в ОС Linux. Помимо описанных Syslog и Rsyslog, в Линуксе существуют также другие механизмы журналирования, да и Rsyslog содержит массу полезных функций. Так что продолжение следует…

Что такое инфраструктура как код? Что значит «сервера снежинки»? Как автоматизировать работу с серверами? Ответы на эти и другие вопросы дадим на бесплатном уроке, после которого вы узнаете как автоматизировать рутинные процессы создания и настройки серверов с помощью инструментов vagrant, terraform, ansible.

Зарегистрироваться на бесплатный урок

Источник: temofeev.ru

Настройка аудита смены паролей пользователей AD с Powershell и Event Viewer

Используя групповые политики Active Directory можно настроить аудит смены паролей и других действий связанные с пользователями. Эти события можно получить используя оснастку Event Viewer и Powershell. В этой статье мы разберем эти возможности на примерах и создадим команду Powershell, которая сделает этот процесс более простым.

Навигация по посту

Настройка политики аудита
Получение событий

Фильтрация логов с Event Viewer
Фильтрация логов с Powershell

Примеры работы

Настройка политики аудита

Самый удобный способ создать политику — использовать оснастку ‘Group Policy Management’. Эта оснастка может быть открыта через RSAT или на домен-контроллер. Оснастку групповых политик так же открывается командой:

gpedit.msc

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

В примерах я использую OU Moscow. Через Powershell создать и привязать политику тоже можно. Это делается следующим образом:

# Создаем политику $gpo = New-GPO -Name ‘PasswordAudit’ # Соединяем политику с OU Moscow New-GPLink -Name ‘PasswordAudit’ -Target ‘OU=Moscow,DC=domain,DC=local’

Политика, которая нам нужна, называется ‘Audit account management/Аудит управления учетной записью’. Она включает аудит связанный с изменением пользователя, пароля и групп. Что бы это сделать пройдите по следующему пути

‘Computer Configuration’ — ‘Policies’ — ‘Windows Settings’ — ‘Security Settings’ — ‘Local Policies’ = ‘Audit Policy’;
‘Конфигурация компьютера’ — ‘Параметры Windows’ — ‘Параметры безопасности’ — ‘Локальные политики’ — ‘Политика аудита’.

В этой политике нужно включить учет успешных попыток изменения данных (Success) и провала (Failure):

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

Ниже, для примера, показано как через Powershell устанавливается политика включающая заставку через 900 секунд:

# Set-GPRegistryValue -Name «Созданная политика» -Key «HKCUSoftwarePoliciesMicrosoftWindowsControl PanelDesktop» -ValueName «ScreenSaveTimeOut» -Type DWORD -Value 900

У домен контроллеров есть роль FSMO, которая отвечает за пароли. Ее название PDC — ‘Primary domain controller’. На домен контроллере, который держит эту роль, и будут собираться все события связанные с политикой аудита. Увидеть кому принадлежит эта роль можно так:

(Get-ADDomain).PDCEmulator

На клиентских компьютерах запустим обновление политик:

Invoke-GPUpdate -Force -Target ‘Computer’

Получение событий

Учитывая, что включенная политика касается не только паролей, можно настроить фильтр через Powershell или GUI. Мы настроим фильтры, которые будут выводить события связанные с определенными идентификаторами ‘Event ID’. Нас интересуют следующие идентификаторы:

4723 — попытка смены пароля;
4724 — попытка сброса пароля;
4740 — пользователь был заблокирован;
4767 — пользователь был разблокирован.

Фильтрация логов с Event Viewer

Что бы выполнить фильтрацию через GUI — откройте логи ‘Security’ в ‘Event Viewer’ на домен-контроллере. Открыв журнал вы увидите множество событий не касающихся паролей:

Эти фильтры мы можем применить зайдя в соответствующее меню:

В новом окне мы должны указать идентификаторы событий, их источник и категорию:

После этих установок у нас будут отображаться только нужные события.

Фильтрация логов с Powershell

В Powershell есть две команды для работы с логами:

Get-WinEvent — получает логи из всех журналов;
Get-Eventlog — получает логи из журналов Application, System, or Security. Является устаревшим командлетом.

Обе команды имеют параметр ‘ComputerName’, с помощью которого можно подключаться удаленно.

У получения логов средствами Powershell есть две проблемы:

Процесс получения логов медленный. Выполнение одного запроса может выполняться больше 1 секунды;
Если брать другие команды Powershell, то их вывод всегда структурирован в виде ‘Ключ’=’Значение’. При получении логов журнала, так же как в EventViewer, часть информации будет представлена как строка, т.е ‘Ключ’= ‘Ключ=Значение Ключ=Значение’. В разных случаях может придется использовать регулярные выражения и парсить значения.

Что бы максимально ускорить процесс получения логов можно использовать 3 параметра фильтрации: FilterXPath, FilterHashtable, FilterXml.

XPath — это язык запросов, который был создан для работы с XML. Мы можем не создавать свой запрос XPath, а увидеть уже составленный на созданном раннее фильтре, на вкладке XML:

Команда, которая получит подобные логи с домен-контроллера ‘AD1’ и используя запрос XPath, будет выглядеть следующим образом:

Аналогичное можно сделать использовав HashTable. Мы не должны указывать тип логов, т.к. это сделано в массиве:

Если вам больше нравится вариант с запросом через hashtable, но вы не понимаете как правильно его составить, можно использовать следующий подход. Мы должны найти хоть один лог, который нам нужен используя любые средства Powerhsell. Затем мы выводим все свойства через ‘SELECT *’ и заполняем ими нашу таблицу:

Get-WinEvent -ComputerName ‘AD1’ -LogName ‘Security’ | where id -eq 4634 | select *

Отличия между массивом hashtable и обычными средствами Powershell в скорости. Если вы будете фильтровать вывод используя Powerhsell (как в примере выше) — это будет медленнее. Кроме указанных параметров в документации можно найти дополнительные варианты.

Создание команды

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

возможность указания времени, указывающие на начало создания лога;
понятный вывод сообщения соответствующий идентификаторам;
источник и цель аудита. Например администратор изменивший пароль пользователя;
тип события — success или fail.

Что бы получить события начинающиеся с определенной даты мы можем использовать существующее свойство ‘StartTime’ в массиве. ‘EndTime’ указывает обратное. В примере ниже мы получим события созданные за сутки:

Выше уже описывалась, что одна из проблем работы с журналом — это отсутствие форматирования каких-то данных. В примере ниже свойство ‘Messages’ хранит сплошной текст, а ‘Properties’ только некоторые отформатированные данные из ‘Messages’:

(Get-WinEvent -ComputerName ‘AD1’ -FilterHashtable $hash -MaxEvents 1).Message (Get-WinEvent -ComputerName ‘AD1’ -FilterHashtable $hash -MaxEvents 1).Properties

Пример выше — скорее идеальный случай. У вас может отличаться порядок или другая информация в ‘Properties’. Эти данные точно будут отличаться в логах с разными ID. В случае с одинаковыми ID — это так же может случатся.

Готовая функция, выводящая информацию об этих событиях, будет следующей:

Примеры работы

Варианты использования функции:

# возвращаем все события по идентификаторам 4723,4724,4740,4767 Get-ADPasswordEvent # возвращаем те же события, но за сутки Get-ADPasswordEvent -BeginTime (Get-Date).AddDays(-1) # возвращаем события провала с удаленного компьютера Get-ADPasswordEvent -ComputerName ‘AD1’ -EventType ‘Failure’ # возвращаем события используя другой идентификатор Get-ADPasswordEvent -EventID 4724

Источник: fixmypc.ru