Лог изменений файлов: Аудит удаления и доступа к файлам и запись событий в лог-файл средствами Powershell

Аудит удаления и доступа к файлам и запись событий в лог-файл средствами Powershell

Я думаю, многие сталкивались с задачей, когда к Вам приходят и спрашивают: «У нас тут файл пропал на общем ресурсе, был и не стало, похоже кто-то удалил, Вы можете проверить кто это сделал?» В лучшем случае вы говорите, что у вас нет времени, в худшем пытаетесь найти в логах упоминание данного файла. А уж когда включен файловый аудит на файловом сервере, логи там, мягко говоря «ну очень большие», и найти что-то там — нереально.
Вот и я, после очередного такого вопроса (ладно бекапы делаются несколько раз в день) и моего ответа, что: «Я не знаю кто это сделал, но файл я Вам восстановлю», решил, что меня это в корне не устраивает…

Начнем.

Для начала включим к групповых политиках возможность аудита доступа к файлам и папкам.
Локальные политики безопасности->Конфигурация расширенной политики безопасности->Доступ к объектам
Включим «Аудит файловой системы» на успех и отказ.
После этого на необходимые нам папки необходимо настроить аудит.
Проходим в свойства папки общего доступа на файловом сервере, переходим в закладку «Безопасность», жмем «Дополнительно», переходим в закладку «Аудит», жмем «Изменить» и «Добавить». Выбираем пользователей для которых вести аудит. Рекомендую выбрать «Все», иначе бессмысленно. Уровень применения «Для этой папки и ее подпапок и файлов».
Выбираем действия над которыми мы хотим вести аудит. Я выбрал «Создание файлов/дозапись данных» Успех/Отказ, «Создание папок/дозапись данных» Успех/отказ, Удаление подпапок и файлов и просто удаление, так же на Успех/Отказ.
Жмем ОК. Ждем применения политик аудита на все файлы. После этого в журнале событий безопасности, будет появляться очень много событий доступа к файлам и папкам. Количество событий прямопропорционально зависит от количества работающих пользователей с общим ресурсом, и, конечно же, от активности использования.

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

#Задаем период, в течении которого мы будем запускать один раз скрипт, и искать нужные нам события. Здесь период задан - 1 час. Т.е. проверяются все события за последний час.
$time =  (get-date) - (new-timespan -min 60)

#$BodyL - переменная для записи в лог-файл
$BodyL = ""

#$Body - переменная, в которую записываются ВСЕ события с нужным ID. 
$Body = Get-WinEvent -FilterHashtable @{LogName="Security";ID=4663;StartTime=$Time}|where{ ([xml]$_.ToXml()).Event.EventData.Data |where {$_.name -eq "ObjectName"}|where {($_.'#text') -notmatch ".*tmp"} |where {($_.'#text') -notmatch ".*~lock*"}|where {($_.'#text') -notmatch ".*~$*"}} |select TimeCreated, @{n="Файл_";e={([xml]$_.ToXml()).Event.EventData.Data | ? {$_.Name -eq "ObjectName"} | %{$_.'#text'}}},@{n="Пользователь_";e={([xml]$_.ToXml()).Event.EventData.Data | ? {$_.Name -eq "SubjectUserName"} | %{$_.'#text'}}} |sort TimeCreated

#Далее в цикле проверяем содержит ли событие определенное слово (к примеру название шары, например: Secret)	
foreach ($bod in $body){
	if ($Body -match ".*Secret*"){

#Если содержит, то пишем в переменную $BodyL данные в первую строчку: время, полный путь файла, имя пользователя. И #в конце строчки переводим каретку на новую строчку, чтобы писать следующую строчку с данными о новом файле. И так #до тех пор, пока переменная $BodyL не будет содержать в себе все данные о доступах к файлам пользователей.

		$BodyL=$BodyL+$Bod.TimeCreated+"`t"+$Bod.Файл_+"`t"+$Bod.Пользователь_+"`n"
	}
}

#Т.к. записей может быть очень много (в зависимости от активности использования общего ресурса), то лучше разбить лог #на дни. Каждый день - новый лог. Имя лога состоит из Названия AccessFile и даты: день, месяц, год.
$Day = $time.day
$Month = $Time.Month
$Year = $Time.Year
$name = "AccessFile-"+$Day+"-"+$Month+"-"+$Year+".txt"
$Outfile = "\serverServerLogFilesAccessFileLog"+$name

#Пишем нашу переменную со всеми данными за последний час в лог-файл.
$BodyL | out-file $Outfile -append

А теперь очень интересный скрипт.

Скрипт пишет лог об удаленных файлах.

#Переменная $Time тут имеет такое же назначение как в предыдущем скрипте.

$time =  (get-date) - (new-timespan -min 60)

#$Events - содержит время и порядковый номер записи евента с ID=4660. И сортируем по порядковому номеру.
#!!!!Это важное замечание!!! При удалении файла создается сразу 2 записи, с ID=4660 и ID=4663.
$Events = Get-WinEvent -FilterHashtable @{LogName="Security";ID=4660;StartTime=$time} | Select TimeCreated,@{n="Запись";e={([xml]$_.ToXml()).Event.System.EventRecordID}} |sort Запись

#Самые важные команды поиска. Опишу принцип ниже, после листинга скрипта.
$BodyL = ""
$TimeSpan = new-TimeSpan -sec 1
foreach($event in $events){
	$PrevEvent = $Event.Запись
	$PrevEvent = $PrevEvent - 1
	$TimeEvent = $Event.TimeCreated
	$TimeEventEnd = $TimeEvent+$TimeSpan
	$TimeEventStart = $TimeEvent- (new-timespan -sec 1)
	$Body = Get-WinEvent -FilterHashtable @{LogName="Security";ID=4663;StartTime=$TimeEventStart;EndTime=$TimeEventEnd} |where {([xml]$_.ToXml()).Event.System.EventRecordID -match "$PrevEvent"}|where{ ([xml]$_.ToXml()).Event.EventData.Data |where {$_.name -eq "ObjectName"}|where {($_.'#text') -notmatch ".*tmp"} |where {($_.'#text') -notmatch ".*~lock*"}|where {($_.'#text') -notmatch ".*~$*"}} |select TimeCreated, @{n="Файл_";e={([xml]$_.ToXml()).Event.EventData.Data | ? {$_.Name -eq "ObjectName"} | %{$_.'#text'}}},@{n="Пользователь_";e={([xml]$_.ToXml()).Event.EventData.Data | ? {$_.Name -eq "SubjectUserName"} | %{$_.'#text'}}} 
	if ($Body -match ".*Secret*"){
		$BodyL=$BodyL+$Body.TimeCreated+"`t"+$Body.Файл_+"`t"+$Body.Пользователь_+"`n"
	}
}


$Month = $Time.Month
$Year = $Time.Year
$name = "DeletedFiles-"+$Month+"-"+$Year+".txt"
$Outfile = "\serverServerLogFilesDeletedFilesLog"+$name


$BodyL | out-file $Outfile -append

Как оказалось при удалении файлов и удалении дескрипторов создается одно и тоже событие в логе, под ID=4663. При этом в теле сообщения могут быть разные значения «Операции доступа»: Запись данных (или добавление файла), DELETE и т.д.

Конечно же нас интересует операция DELETE. Но и это еще не все. Самое интересное, то что, при обычном переименовании файла создается 2 события с ID 4663, первое с Операцией доступа: DELETE, а второе с операцией: Запись данных (или добавление файла). Значит если просто отбирать 4663 то мы будем иметь очень много недостоверной информации: куда попадут файлы и удаленные и просто переименованные.

Однако мной было замечено, что при явном удалении файла создается еще одно событие с ID 4660, в котором, если внимательно изучить тело сообщения, содержится имя пользователя и еще много всякой служебной информации, но нет имени файла. Зато есть код дескриптора.

Однако предшествующим данному событию было событие с ID 4663. Где как раз таки и указывается и имя файла, и имя пользователя и время, и операция как не странно там DELETE. И самое главное там имеется номер дескриптора, который соответствует номеру дескриптора из события выше (4660, помните? которое создается при явном удалении файла). Значит теперь, чтобы точно знать какие файлы удалены, необходимо просто найти все события с ID 4660, а так же предшествующие каждому этому событию, событие с кодом 4663, в котором будет содержаться номер нужного дескриптора.

Эти 2 события генерируются одновременно при удалении файла, но записываются последовательно, сначала 4663, потом 4660. При этом их порядковые номера различаются на один. У 4660 порядковый номер на единицу больше чем у 4663.

Именно по этому свойству и ищется нужное событие.

Т.е. берутся все события с ID 4660. У них берется 2 свойства, время создания и порядковый номер.

Далее в цикле по одному берется каждое событие 4660. Выбирается его свойства, время и порядковый номер.

Далее в переменную $PrevEvent заносится номер нужного нам события, где содержится нужная информация об удаленном файле. А так же определяются временные рамки в которых необходимо искать данное событие с определенным порядковым номером (с тем самым который мы занесли в $PrevEvent). Т.к. событие генерируется практически одновременно, то поиск сократим до 2х секунд: + — 1 секунда.

(Да, именно +1 сек и -1 сек, почему именно так, не могу сказать, было выявлено экспериментально, если не прибавлять секунду, то некоторые может не найти, возможно связано с тем, что возможно два эти события могут создаваться один раньше другой позже и наоборот).

Сразу оговорюсь, что искать только по порядковому номеру по всем событиям в течении часа — очень долго, т.к. порядковый номер находиться в теле события, и чтобы его определить, нужно пропарсить каждое событие — это очень долго. Именно поэтому необходим такой маленький период в 2 секунда (+-1сек от события 4660, помните?).

Именно в этом временном промежутке ищется событие с необходимым порядковым номером.

После того как оно найдено, работают фильтры:

|where{ ([xml]$_.ToXml()).Event.EventData.Data |where {$_.name -eq "ObjectName"}|where {($_.'#text') -notmatch ".*tmp"} |where {($_.'#text') -notmatch ".*~lock*"}|where {($_.'#text') -notmatch ".*~$*"}}

Т.е. не записываем информацию об удаленных временных файлах (.*tmp), файлах блокировок документов MS Office (.*lock), и временных файлах MS Office (.*~$*)
Таким же образом берем необходимые поля из этого события, и пишем их в переменную $BodyL.
После нахождения всех событий, пишем $BodyL в текстовый файл лога.

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

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

Рекомендации

Вам придется самим определить время в течении которого вы будете искать нужные события. Чем больше период, тем дольше ищет. Все зависит от производительности сервера. Если слабенький — то начните с 10 минут. Посмотрите, как быстро отработает. Если дольше 10 минут, то либо увеличьте еще, вдруг поможет, либо наоборот уменьшите период до 5 минут.

После того как определите период времени. Поместите данный скрипт в планировщик задач и укажите, что выполнять данный скрипт необходимо каждые 5,10,60 минут (в зависимости какой период вы указали в скрипте). У меня указано каждый 60 минут. $time = (get-date) — (new-timespan -min 60).

PS

У меня оба эти скрипта работают для сетевого ресурса в 100Гб, на котором ежедневно активно работают в среднем 50 пользователей.
Время поиска удаленных файлов за час — 10-15 минут.
Время поиска всех файлов, к которым был доступ — от 3 до 10 минут. В зависимости от нагрузки на сервер.

Вертим логи как хотим ― анализ журналов в системах Windows / Блог компании Сервер Молл / Хабр

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

В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.

До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:

findstr "Fail" *.log >> fail.txt

Она позволяла получить в файле fail.txt все ошибки обмена. Но если было нужно что-то большее, вроде получения информации о предшествующей ошибке, то приходилось создавать монструозные скрипты с циклами for или использовать сторонние утилиты. По счастью, с появлением PowerShell эти проблемы ушли в прошлое.

Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:

Get-Content -Path 'C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log' | Out-Host -Paging

Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:

>Get-Content -Path "C:\Windows\WindowsUpdate.log" -Tail 5 -Wait

Смотрим за ходом обновления Windows.

Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:

Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern 'Drop' | Select-Object -Last 20 | Format-Table Line

Смотрим, кто пытается пролезть на наш дедик.

При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:

Select-String 'C:\Windows\Cluster\Reports\Cluster.log' -Pattern ' err ' ‑Context 3

Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:

Get-Content 'C:\Windows\debug\netlogon.log' | Select-Object -First 30 -Skip 45

Журналы системы ведутся в формате .evtx, и для работы с ними существуют отдельные командлеты. Для работы с классическими журналами («Приложение», «Система», и т.д.) используется Get-Eventlog. Этот командлет удобен, но не позволяет работать с остальными журналами приложений и служб. Для работы с любыми журналами, включая классические, существует более универсальный вариант ― Get-WinEvent. Остановимся на нем подробнее.

Для получения списка доступных системных журналов можно выполнить следующую команду:

Get-WinEvent -ListLog *

Вывод доступных журналов и информации о них.

Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:

Get-WinEvent -LogName 'System' -MaxEvents 20

Последние записи в журнале System.

Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.

Для примера получим все события из журнала System с кодом события 1 и 6013.

Get-WinEvent -FilterHashTable @{LogName='System';ID='1','6013'}

В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:

• 0 ― всегда записывать;
• 1 ― критический;
• 2 ― ошибка;
• 3 ― предупреждение;
• 4 ― информация;
• 5 ― подробный (Verbose).

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

Get-WinEvent -FilterHashtable @{LogName='system'} | Where-Object -FilterScript {($_.Level -eq 2) -or ($_.Level -eq 3)}

Ошибки и предупреждения журнала System.

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

Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:

PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.

Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.

О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.

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

SELECT 
 extract_token(text, 0, ' ') as date, 
 extract_token(text, 1, ' ') as time,
 extract_token(text, 2, ' ') as action, 
 extract_token(text, 4, ' ') as src-ip,  
 extract_token(text, 7, ' ') as port 
FROM 'C:\Windows\System32\LogFiles\Firewall\pfirewall.log' 
WHERE action='DROP' AND port='3389'
ORDER BY date,time DESC

Посмотрим на результат:

Смотрим журнал Windows Firewall.

Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.

Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.

Работать будем с журналом TerminalServices-LocalSessionManager\Operational.

Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%\test.evtx.

Данные будем получать таким запросом:

SELECT
 timegenerated as Date, 
 extract_token(strings, 0, '|') as user,
 extract_token(strings, 2, '|') as sourceip 
FROM '%temp%\test.evtx'
WHERE EventID = 21
ORDER BY Date DESC

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

Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.

В качестве примера посмотрим статистику количества писем по дням таким запросом:

SELECT
 TO_LOCALTIME(TO_TIMESTAMP(EXTRACT_PREFIX(TO_STRING([#Fields: date-time]),0,'T'), 'yyyy-MM-dd')) AS Date,
 COUNT(*) AS [Daily Email Traffic] 
FROM 'C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking\*.LOG'
WHERE (event-id='RECEIVE') GROUP BY Date ORDER BY Date ASC

Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.

Выполняем запрос и открываем получившуюся картинку…

Любуемся результатом.

Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.

$LogQuery = New-Object -ComObject "MSUtil.LogQuery"
$InputFormat = New-Object -ComObject "MSUtil.LogQuery.FileSystemInputFormat"
$InputFormat.Recurse = -1
$OutputFormat = New-Object -ComObject "MSUtil.LogQuery.CSVOutputFormat"
$SQLQuery = "SELECT Top 20 Path, Size INTO '%temp%\output.csv' FROM 'C:\*.*' ORDER BY Size DESC"
$LogQuery.ExecuteBatch($SQLQuery, $InputFormat, $OutputFormat)
$CSV = Import-Csv  $env:TEMP'\output.csv'
$CSV | fl 
Remove-Item $env:TEMP'\output.csv'
$LogQuery=$null
$InputFormat=$null
$OutputFormat=$null

Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.

Благодаря этой возможности для облегчения работы существует несколько утилит, представляющих из себя графическую оболочку для Log Parser. Платные рассматривать не буду, а вот бесплатную Log Parser Studio покажу.

Интерфейс Log Parser Studio.

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

Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.

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

Выборка наиболее активных ящиков.

При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.

Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.

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

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

Пользовательская рабочая станция — самое уязвимое место инфраструктуры по части информационной безопасности. Пользователям может прийти на рабочую почту письмо вроде бы из безопасного источника, но со ссылкой на заражённый сайт. Возможно, кто-то скачает полезную для работы утилиту из неизвестно какого места. Да можно придумать не один десяток кейсов, как через пользователей вредоносное ПО может внедриться на внутрикорпоративные ресурсы. Поэтому рабочие станции требуют повышенного внимания, и в статье мы расскажем, откуда и какие события брать для отслеживания атак.

Для выявления атаки на самой ранней стадии в ОС Windows есть три полезных событийных источника: журнал событий безопасности, журнал системного мониторинга и журналы Power Shell.

Журнал событий безопасности (Security Log)

Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.

Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.

Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.

Попытки входа с локальной учётной записью (событие 4624). Добропорядочные пользователи заходят с доменной учётной записью и выявление входа под локальной учётной записью может означать начало атаки. Событие 4624 включает также входы под доменной учетной записью, поэтому при обработке событий нужно зафильтровать события, в которых домен отличается от имени рабочей станции.

Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.

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

Изменения конфигурации файрволла (события 4944-4958). Очевидно, что при установке нового ПО настройки конфигурации файрволла могут меняться, что вызовет ложные срабатывания. Контролировать такие изменения в большинстве случаев нет необходимости, но знать о них точно лишним не будет.

Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.

Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:

Logon/Logoff

• Logon;
• Logoff;
• Account Lockout;
• Other Logon/Logoff Events.

Account Management

• User Account Management;
• Security Group Management.

Policy Change

• Audit Policy Change;
• Authentication Policy Change;
• Authorization Policy Change.

Системный монитор (Sysmon)

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

Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но Sysmon даёт больше подробностей. Какие события можно забирать из Sysmon?

Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.

Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.

Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.

Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.

А теперь то, чего в политиках Security Log нет, но есть в Sysmon:

Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.

Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.

Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.

События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\\.\”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.

Создание именованного файлового потока (ID события 15). Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хэшем содержимого файла.

Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.

Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.

Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).

Журналы Power Shell

Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.

Windows PowerShell log

Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.

Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)

Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.

Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.

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

Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.

как это делается в разных ОС / Хабр

Я бы хотел посвятить статью обзору API, предоставляемых разными ОС для слежения за изменениями в директории. Статья появилась как результат моей работы над демонами слежения за изменениями для утилиты dklab_realsync (статья на хабре, github репозиторий) и своей собственной, которую я пока что не хочу анонсировать.

Для операционной системы Windows есть замечательная функция ReadDirectoryChangesW, которая возвращает набор изменений для директории, в том числе содержит флаг для работы рекурсивно (bWatchSubtree). Таким образом, реализация слежения за изменениями в директории не представляет особого труда и в том же dklab_realsync реализация занимает 80 строк кода или 3.5 Кб. Интересно, что в Windows эти события поддерживаются даже через SMB!

Тем не менее, существуют определенные подводные камни:

• конечный размер буфера изменений, после которого очередь событий переполнится и эти события будут потеряны
• согласно документации к watchdog package, событие перемещения посылается раньше, чем изменения становятся видны в ФС
• размер буфера ограничен в 64 Кб для сетевой ФС

Вывод: Функция ReadDirectoryChangesW позволяет легко узнавать обо всех событиях в файлах, но, очередь событий может переполниться и тогда нужно будет выполнять полное сканирование ФС. Также, возможна доставка событий до того, как они станут актуальны.

В Mac OS X также есть удобный и простой API для слежения за изменениями в файловой системе под названием FSEvents. С использованием этого API простейшая реализация демона составляет 50 строк кода или 1.8 кб. Очередь не может переполниться (!), но полное сканирование все же может потребоваться, если демон fseventsd «упадет». Стоит отметить, что этот API до версии 10.7 не предоставляет изменения по файлам, он сообщает только директории, в которых что-то изменилось. Поскольку события никуда не деваются и пишутся в лог (FSEvents service stores events in a persistent, per-volume database), детализация с точностью для директории позволяет сэкономить место на диске.

Вывод: FSEvents API для Mac OS X является самым необычным из всех подобных API. Очередь не переполняется и даже имеется возможность получить события из прошлого. Тем не менее, детализация событий дается с точностью до директории (до версии 10.7), что означает меньшую эффективность демона для синхронизации файлов.

В linux vanilla kernel существует один способ слежения за изменениями в директории — это inotify. Для этого API существует хорошая и подробная документация, но нет поддержки рекурсивного слежения за изменениями! Также, у inotify есть ограничение на максимальное количество объектов, за которыми можно следить. Простейшая реализация демона занимает уже 250 строк кода или 8 кб. Статическая сборка с использованием dietlibc занимает примерно 14 кб. Другим неприятным моментом является то, что приложение должно само поддерживать соответствия между watch descriptor (в нашем случае это всегда директория) и именем. Есть функция inotify_add_watch, которой передается путь до отслеживаемой директории, но нет обратной — inotify_get_path, которая бы возвращала этот самый путь по переданному дескриптору. События же содержат только watch descriptor и относительный путь до изменившегося файла внутри директории.

Подводные камни рекурсивного слежения за директорией через inotify:

• Возможность переполнения очереди (длина очереди задается в /proc/sys/fs/inotify/max_queued_events)
• Ограничение на максимальное количество объектов слежения (задается в /proc/sys/fs/inotify/max_user_watches)
• Отсутствие возможности рекурсивного слежения за директорией
• Необходимость отдельно обрабатывать случай, когда создается директория (например mkdir -p a/b/c). Вы получите событие о том, что создана директория «a», но пока вы навешиваете обработчик на эту директорию, в ней уже могут создать ещё одну директорию и событие об этом вам уже не придет.
• Теоретическая возможность целочисленного переполнения watch descriptor (wd), так как он задается uint32

FreeBSD и Mac OS X позволяют отслеживать за изменениями с помощью kqueue, который аналогичен inotify по своим характеристикам и также не имеет возможности рекурсивного слежения за директориями. Также, kqueue принимает в качестве аргументов дескрипторы открытых файлов (директорий), поэтому при использовании этого API ограничения на количество отслеживаемых директорий ещё более строгие.

Как можно видеть, у всех API существуют свои достоинства и недостатки. Наименее удобными являются механизмы kqueue и inotify, но они же являются самыми эффективными и надежными. Коммерческие ОС предоставляют более удобные механизмы слежения за изменениями, но у них тоже есть свои особенности. Надеюсь, теперь вы имеете больше представления о том, как тяжела участь Dropbox и подобных программ, которым требуется со всем этим уживаться и осуществлять надежную и эффективную синхронизацию данных :).

* Картинка взята с www.alexblogger.com/2008_01_01_archive.html

Ведение журнала сделанных в книге изменений

Хитрости »
1 Май 2011       Дмитрий       238572 просмотров

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

Отслеживание изменений при помощи встроенных средств — Общий доступ к книге
Есть относительно простой способ отслеживать изменения(если это можно так назвать): дать книге общий доступ
Excel 2007 и выше: вкладка Рецензирование(Review) —Доступ к книге(Share workbook). В появившемся окне поставить галочку разрешить изменять файл нескольким пользователям одновременно(Allow changes by more then one user at the same time):

Далее можно настроить срок хранения лога изменений, конфликты и пр — вкладка Подробнее(Advanced):

Регистрация изменений(Track changes)

• Хранить журнал в течение(keep change history for): — если необходимо вести журнал изменений(а нам необходимо!) то оставляем этот пункт включенным и устанавливаем количество дней, в течение которых необходимо сохранять историю. По умолчанию это 30 дней. Здесь имеются ввиду последние 30 дней от текущей даты. Т.е. по истечению этих 30 дней более ранние данные истории будут затерты
• Не хранить журнал изменений(don’t keep change history): после выбора этого пункта и подтверждения журнал будет удален(если он был создан) и история вестись не будет

Обновлять изменения

• При сохранении файла(When file is saved) — это самый оптимальный вариант. Данные об изменениях в файле будут обновляться только тогда, когда мы сами сохраним файл.
• Каждые(Automatically every): указывается промежуток времени в минутах, через который книга сама автоматически будет сохраняться и регистрировать изменения. Не очень удобен данный пункт если в файле одновременно работает несколько человек. При этом необходимо будет обязательно выбрать какое действие будет производится по умолчанию:
  • сохранить мои изменения и просмотреть чужие(save my changes and see others’ changes)
  • только просмотреть чужие изменения(just see other users’ changes)

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

Для противоречивых изменений(Conflicting changes between users)

данный пункт управляет разрешением конфликтов, если при одновременном пользовании файлом несколькими пользователями два и более пользователя сделали изменения в одной и той же ячейке листа.
• запрашивать чьи изменения имеют преимущество(ask me which changes win) — самый оптимальный вариант. Первый, открывший файл пользователь определяет какие изменения надо принять, а какие отклонить
• ранее сохраненные имеют преимущество(the changes being saving win) — не очень правильный вариант, но все зависит от ситуации. По логике при данном пункте при возникновении конфликта автоматически будут приняты лишь те изменения, которые были сделаны ранее. Может сыграть нехорошую шутку, поэтому надо быть острожным с этим пунктом

Включить в личное представление(Include in personal view)

Данный пункт управляет настройками печати и фильтра общей книги для нескольких пользователей.
• параметры печати(Print settings) — Обычно, в одном файле когда мы настраиваем параметры печати, они сохраняются внутри файла и при следующем открытии их не надо уже заново настраивать. Здесь тоже самое, но хранится для каждого пользователя отдельно. Т.е. даже если в этом файле один пользователь настроил одни параметры печати, а другой – иные, то для каждого пользователя эти параметры сохраняться. В обычной книге применились бы те параметры, которые были назначены перед последним сохранением книги.
• фильтры(Filter settings) — если один пользователь отфильтровал данные по «Юго-Восточный округ», а другой тот же столбец по «Северный округ», то при установленном данном пункте у каждого пользователя файл откроется с отфильтрованными строками именно по установленным ими параметрам — для каждого свой

Но оба эти пункта имеют большой недостаток: в зависимости от количества пользователей и их действий они могут сильно «раздувать» файл и приводить к значительным его «тормозам». Поэтому без необходимости лучше их не использовать

Теперь самое главное: как увидеть все сделанные изменения
После того, как пользователи поработали с файлом и стало необходимо увидеть сделанные изменения необходимо перейти на вкладке Рецензирование(Review) —Исправления(Track changes) —Выделить исправления(Highlight changes)

Здесь можно выбрать какие изменения показывать

• по времени(When) — если хотите увидеть только какие-то конкретные изменения, то надо установить галочку на этом пункте и выбрать нужное. Доступно выбрать: Со времени последнего сохранения, Все, Еще не просмотрено, С даты. Пункты достаточно красноречивы и понятны, расписывать каждый не вижу смысла. Если хотите просмотреть все изменения — галочку с этого пункта надо снять
• пользователем(Who) можно показать изменения, сделанные конкретным пользователем, всеми пользователями, или всеми пользователями, кроме того, кто запросил отчет об изменениях(т.е. кроме себя любимого)
• в диапазоне(Where) можно указать конкретный диапазон на листе и отчет об изменения будет выведен только для ячеек этого диапазона.

Выделять исправления на экране(Highlight changes on screen): если установить эту галочку, то изменения будут созданы в виде примечаний к ячейкам, изменения в которых были сделаны. В левом верхнем углу ячейки в этом случае появится черный треугольник, а при наведении на эту ячейку появится примечание с информацией о том кто изменил, когда и на что:

Вносить изменения на отдельный лист(List changes on a new sheet): в этом случае будет создан новый лист с именем «Журнал», в котором будут перечислены ячейки, в которые были внесены изменения с указанием даты и времени изменения, пользователя сделавшего изменение, старое и новое значение измененной ячейки:

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

Но самый главный недостаток: книги в общем доступе имеют ряд ограничений, среди которых такие как:

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

Плюс невозможно не только использовать умные таблицы, но и сделать книгу общей, если в ней есть хоть одна умная таблица. Если будет попытка сделать общий доступ к книге с умной таблицей Excel покажет предупреждение, что этого делать нельзя и проинструктирует как преобразовать такую таблицу в диапазон для возможности использовать общий доступ.
Так же хочу отметить, что есть распространенное заблуждение о невозможности использования макросов в книгах с общим доступом. Это не так, коды Visual Basic for Applications разрешается применять и в большинстве случаев они будут работать корректно и как задумывались, если они только не пытаются произвести действия, перечисленные как запрещенные для книг с общим доступом. Плюс невозможно просматривать и изменять коды в книгах с общим доступом.

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

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

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

Option Explicit
Public sValue As String
Private Sub Workbook_SheetChange(ByVal Sh As Object, ByVal Target As Range)
    If Sh.Name = "LOG" Then Exit Sub
    Dim sLastValue As String
    Dim lLastRow As Long
 
    With Sheets("LOG")
        lLastRow = .Cells.SpecialCells(xlLastCell).Row + 1
        If lLastRow = Rows.Count Then Exit Sub
        Application.ScreenUpdating = False: Application.EnableEvents = False
        .Cells(lLastRow, 1) = CreateObject("wscript.network").UserName
        .Cells(lLastRow, 2) = Target.Address(0, 0)
        .Cells(lLastRow, 3) = Format(Now, "dd.mm.yyyy HH:MM:SS")
        .Cells(lLastRow, 4) = Sh.Name
        .Cells(lLastRow, 5).NumberFormat = "@"
        .Cells(lLastRow, 5) = sValue
        If Target.Count > 1 Then
            Dim rCell As Range, rRng As Range
            On Error Resume Next
            Set rRng = Intersect(Target, Sh.UsedRange): On Error GoTo 0
            If Not rRng Is Nothing Then
                For Each rCell In rRng
                    If Not IsError(Target) Then sLastValue = sLastValue & "," & rCell Else sLastValue = sLastValue & "," & "Err"
                Next rCell
                sLastValue = Mid(sLastValue, 2)
            Else
                sLastValue = ""
            End If
        Else
            If Not IsError(Target) Then sLastValue = Target.Value Else sLastValue = "Err"
        End If
        .Cells(lLastRow, 6).NumberFormat = "@"
        .Cells(lLastRow, 6) = sLastValue
    End With
    Application.ScreenUpdating = True: Application.EnableEvents = True
End Sub
 
Private Sub Workbook_SheetSelectionChange(ByVal Sh As Object, ByVal Target As Range)
    If Sh.Name = "LOG" Then Exit 

Powershell — логирование в файл / Хабр

Доброго времени суток, $username!

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

Функция была написана для того, чтобы информация выводилась и на экран и в лог (текстовый), предназначается для замены стандартного write-host.

Из вкусностей:

• Точная дата и время события
• Тип события
• Подсчет ошибок и предупреждений
• Вывод информации цветом (в зависимости от типа события)
• Формат лога совместим с CSV ([TAB] separated)

Функция объявлена глобально, это значит что в пределах одной сессии достаточно один раз ее проиницилизировать — читай запустить файл с ней.

Варианты использования:
write-log "Hello Хабр!"

14.07.2011 00:22:15 info Hello Хабр!

write-log -message "Hello Хабр!" -type warning

write-log -message «Hello Хабр!» -type error -silent

Правда, путь должен существовать:

write-log -message «Hello Хабр!» -type CustomType logfile c:\enter\your\path\here.log

Количество ошибок и предупреждений (за всю сессию или до ручного обнуления переменных) хранятся в $errorcount и $warningcount.

Лично у меня эта функция храниться в файле set-functions.ps1, и в скриптах я ее вызываю так:

Cамое начало любого (там где это необходимо) моего скрипта:

$ver="0.1"
$ProgrammName="SomeScriptName"

try
{
	# Функция вывода информации на экран и записи в лог
	./Set-Functions.ps1 #Инициализация функций
	$global:logfilename = "log`\"+ $ProgrammName +".log"
	write-log "$ProgrammName (ver $ver) started."
}
catch 
{		
	return "Error loading functions Set-Functions.ps1"
}

Тело функции write-log:

$ver = "0.4"
$dt=Get-Date -Format "dd-MM-yyyy"
New-Item -ItemType directory log -Force | out-null #Создаю директорию для логов

$global:logfilename="log\"+$dt+"_LOG.log"
[int]$global:errorcount=0 #Ведем подсчет ошибок
[int]$global:warningcount=0 #Ведем подсчет предупреждений

function global:Write-log	# Функция пишет сообщения в лог-файл и выводит на экран.
{param($message,[string]$type="info",[string]$logfile=$global:logfilename,[switch]$silent)	
	$dt=Get-Date -Format "dd.MM.yyyy HH:mm:ss"	
	$msg=$dt + "`t" + $type + "`t" + $message #формат: 01.01.2001 01:01:01 [tab] error [tab] Сообщение
	Out-File -FilePath $logfile -InputObject $msg -Append -encoding unicode
	if (-not $silent.IsPresent) 
	{
		switch ( $type.toLower() )
		{
			"error"
			{			
				$global:errorcount++
				write-host $msg -ForegroundColor red			
			}
			"warning"
			{			
				$global:warningcount++
				write-host $msg -ForegroundColor yellow
			}
			"completed"
			{			
				write-host $msg -ForegroundColor green
			}
			"info"
			{			
				write-host $msg
			}			
			default 
			{ 
				write-host $msg
			}
		}
	}
}

У этого примера есть только один недостаток — она «синхронная», то есть не обрабатывает проблемы одновременной записи в лог-файл. Кто знает как это изменить, прошу в комменты.

Журналы (logs) в MySQL / Песочница / Хабр

В MySQL на данный момент существуют 4 вида журнала (лога) и при достаточно серьёзной работе с базами на MySQL необходимо за ними следить. Например, бинарный лог у нас за сутки набирает около гигабайта, а размер жёсткого диска на сервере ограничен и за ними надо следить. Однако следить следует не только за бинарным логом, так как логи (журналы) в MySQL могут принести немалую пользу.

Итак, какие логи ведёт MySQL? Это:

1. бинарный лог (binary log)

2. лог ошибок (error log)

3. лог медленный запросов (slow query log)

4. лог запросов (general query log)

5. лог репликаций (relay log)

Каждый из них по-своему полезен.

Бинарный лог

В первую очередь полезен с точки зрения репликаций. Можно его бэкапить, можно использовать для восстановления данных на более точное время при использовании бэкапов. Лог содержит все команды изменений базы данных, выборки (select, show) не сохраняет, для таблиц, поддерживающих транзакции (BDB, InnoDB) запись в лог выполняется только после выполнения команды COMMIT. Для лога можно указывать список баз данных, которые надо логировать и список баз данных, которые не надо логировать. В более ранних версиях вместо бинарного лога использовался лог обновлений. Использование бинарного лога снижает производительность базы данных, однако его польза настолько велика, что крайне не рекомендуется его отключать. Рекомендуется защищать бинарный лог паролем, так как он может данные также о паролях пользователей. При достижении максимально разрешённого размера (1 гиг по умолчанию) создаётся следующий файл. Каждый новый файл имеет порядковый номер после имени.

Содержание бинарного лога можно посмотреть с помощью утилиты mysqlbinlog.

Основные настройки в my.cnf

Местоположение лога:
log_bin = /var/log/mysql/mysql-bin.log

Максимальный размер, минимум 4096 байт, по умолчанию 1073741824 байт (1 гигабайт):
max_binlog_size= 500M

Сколько дней хранится:
expire_logs_days = 3

Наиболее часто использующиеся команды

Повторение действий после операции восстановления:
shell> mysqlbinlog log_file | mysql -h server_name

Удаление логов до определённого файла:
PURGE BINARY LOGS TO 'mysql-bin.000';

Удаление логов до определённой даты:
PURGE BINARY LOGS BEFORE 'YYYY-MM-DD hh:mm:ss';

Лог ошибок

Особенно полезен в случаях сбоев. Лог содержит информацию об остановках, запусках сервера, а также сообщения о критических ошибках. Может содержать сообщения с предупреждениями (warnings).

Основные настройки в my.cnf

Местоположение лога:
log_error = /var/log/mysql/mysql.err

Флаг, указывающий стоит ли записывать в лог в том числе предупреждения (записываются, если значение больше нуля):
log_warnings = 1

Наиболее часто использующиеся команды

Переход к новому файл лога:
shell> mysqladmin flush-logs

Копирование старой части лога (необходимо, так как в случае повторного выполнения fluch он будет удалён):
shell> mv host_name.err-old backup-directory

Лог медленных запросов

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

Основные настройки в my.cnf

Местоположение лога:
log_slow_queries = /var/log/mysql/mysql_slow.log

Со скольки секунд выполнения запрос считается медленным, минимальное значений — 1 секунда, по умолчанию 10 секунд:
long_query_time = 10

Если надо логировать запросы, которые не используют индексы, надо добавить строку:
log-queries-not-using-indexes

Если надо вести лог медленных команд, таких как OPTIMIZE TABLE, ANALYZE TABLE и ALTER TABLE:
log-slow-admin-statements

Лог запросов

Лог содержит информацию о подключениях и отключениях клиентов, а также все SQL запросы, которые были получены. Фактически, это временный лог. Обычно лог удаляется автоматически сразу после выполнения всех команд (т.е. как только он стал ненужным). Лог ведётся в соответствии с очередность поступления запросов. Этот лог содержит все запросы к базе данных (независимо от приложений и пользователей). Так что если есть желание (или необходимость) проанализировать, какие необходимы индексы, какие запросы могли бы оптимизированы, то этот лог как раз может помочь в таких целях. Лог полезен не только для случаев, когда необходимо знать, какие запросы выполняются с базой данных, но и в случаях, когда ясно, что возникла ошибка с базой данных, но неизвестно, какой запрос был отправлен к базе данных (например, в случае генерации динамического SQL-а). Рекомендуется защищать лог запросов паролем, так как он может данные также о паролях пользователей.

Основные настройки в my.cnf

Местоположение лога:
log = /var/log/mysql/mysql.log

Наиболее часто использующиеся команды

В отличии от других логов, перезагрузка сервера и команда fluch не инициирует создание нового лога. Но это можно сделать вручную:
shell> mv host_name.log host_name-old.log

shell> mysqladmin flush-logs

shell> mv host_name-old.log backup-directory


Лог репликаций

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

Основные настройки в my.cnf

Местоположение лога:
relay-log = /var/log/mysql/mysql-relay-bin.log

Максимальный размер:
max_relay_log_size = 500М

Наиболее часто использующиеся команды

Начать новый файл лога можно только при остановленном дополнительном (slave) сервере:
shell> cat new_relay_log_name.index >> old_relay_log_name.index

shell> mv old_relay_log_name.index new_relay_log_name.index

Команда fluch logs инициирует ротацию лога.

5 способов отслеживания изменений журнала или текстового файла в реальном времени • Raymond.CC

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

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

Решением является использование другого метода, который может автоматически отображать содержимое текстового файла или файла журнала в реальном времени, во многом подобно команде Tail, включенной в Linux и Unix. Есть несколько способов выполнить эту задачу в Windows, здесь мы покажем вам, как это сделать.

Мониторинг текстовых файлов в режиме реального времени с помощью сторонней утилиты

Один из очевидных способов мониторинга файлов журнала или текстовых файлов — использовать отдельный инструмент, который сделает это за вас. Существует несколько программ с разным уровнем сложности, и довольно многие имеют в названии слово «Tail», чтобы отразить тот факт, что они делают то, что делает команда Unix Tail. Мы выбрали несколько инструментов, которые довольно просты в использовании и имеют достаточно возможностей для обычного пользователя.

mTail

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

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

Скачать mTail

SnakeTail

SnakeTail — это небольшая программа с открытым исходным кодом и, по желанию, портативная программа, которая может отслеживать стандартные текстовые файлы или файлы журналов и имеет возможность отслеживать файлы журнала событий непосредственно из меню «Файл». Программа имеет вкладки, поэтому одновременно можно отслеживать более одного файла. Также есть возможность сохранить сеанс мониторинга файлов и вернуться к нему позже.

Пользовательский интерфейс SnakeTail довольно прост в использовании, и вам нужно только перетащить файл в окно, чтобы начать мониторинг.В параметрах просмотра вы можете создать выделенные ключевые слова с выделением текста и возможностью запуска внешней программы, если ключевое слово найдено. Вы можете переключать основные моменты с помощью Alt + Up / Down. Также существует простая система закладок для запоминания определенных строк.

Скачать SnakeTail

Мониторинг изменений текстовых файлов в реальном времени с помощью Notepad ++

Notepad ++ — отличная альтернатива Notepad и один из лучших бесплатных текстовых редакторов с множеством мощных и очень полезных функций.Хотя программа не настроена для отслеживания изменений файлов в реальном времени по умолчанию, с помощью всего лишь нескольких изменений настроек ее можно заставить вести себя таким образом. Когда вы обычно открываете файл в Notepad ++ и его содержимое изменяется из-за внешнего источника, появляется всплывающее окно с сообщением «Этот файл был изменен другой программой. Хотите его перезагрузить? ».

Каждый раз, когда файл обновляется, вам будет отображаться всплывающее окно. Если этот запрос отключен, файл будет автоматически перезагружаться беззвучно при каждом обновлении.В Notepad ++ перейдите в «Настройки»> «Настройки»> «MISC». и установите флажок «Обновление без вывода сообщений». и Прокрутите до последней строки после полей обновления . Второе поле является необязательным и прокручивается до конца файла каждый раз, когда он обновляется и перезагружается.

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

Notepad ++ Мониторинг в фоновом режиме

Если вы хотите, чтобы текстовый файл обновлялся автоматически, когда окно Notepad ++ не в фокусе, альтернативным решением является плагин Document Monitor. Это немного компромисс, потому что период обновления не в реальном времени, а каждые 3 секунды. Перейдите в Plugins> Plugin Manager> Show Plugin Manager, отметьте Document Monitor в списке и нажмите Install .

Загрузите текстовый файл или выберите его открытую вкладку и нажмите Плагины> Монитор документов> Начать мониторинг .Плагин будет сканировать текст или файл журнала на наличие изменений каждые 3 секунды и автоматически прокручивать до конца, чтобы показать обновления, даже если Notepad ++ не является активным окном.

Загрузить Notepad ++

Мониторинг текстового файла из Windows PowerShell в реальном времени

PowerShell интегрирован в Windows, начиная с Windows 7, хотя для XP и Vista доступны отдельные установочные пакеты. В PowerShell доступны более сложные команды, чем в командной строке Windows, и одна из этих команд является встроенной функцией PowerShell для отслеживания текстового файла и отображения изменений.Сама команда довольно проста и работает во всех версиях PowerShell:

Get-content pathtotextfile -Wait

Однако у приведенного выше есть проблема, потому что он выводит все содержимое текстового файла в консоль перед выводом любых дополнительных строк которые добавлены. Чтобы обойти это, вы можете добавить аргумент хвоста, хотя для его использования необходимо запустить PowerShell 3 или выше. Windows 7 имеет версию 2 по умолчанию, поэтому потребуется более новая оболочка PowerShell, в Windows 8, 8.1 и 10 есть PowerShell 3 или новее, так что все будет в порядке.

Get-content pathtotextfile -Tail 0 -Wait

При включении Tail отслеживание файла начнется с конца и не будет сначала отображаться содержимое текстового файла. Если вы хотите включить xx количество строк в конец файла, измените 0 на необходимое число. Также можно фильтровать строки, содержащие определенный текст.

Get-content pathtotextfile -Tail 0 -Wait | где {$ _ -match «ERROR»}

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

Мониторинг текстового файла из командной строки в реальном времени

Хотя нет встроенных инструментов командной строки, которые могут отслеживать изменения текстового файла в реальном времени, есть некоторые из них, основанные на команде Unix Tail. Unxutils — это небольшой набор инструментов, который был перенесен из Unix для работы в Windows. Загрузите UnxUpdates.zip, распакуйте его и поместите Tail.exe и, возможно, Grep.exe в \ Windows, \ System32 или другой папке, найденной в системных переменных PATH. Команда похожа на второй вариант выше:

Tail -n 0 -f pathtotextfile

Аргумент -n аналогичен аргументу PowerShell -tail и просто начинает чтение с конца текстового файла. Чтобы включить только строки, содержащие определенное ключевое слово, используйте команду Grep.

tail -n 0 -f pathtotextfile | Grep Error

Одна проблема почти со всеми доступными портированными утилитами Unix Tail заключается в том, что они довольно старые, это относится к 2003 году.Тем не менее, при базовом тестировании он, похоже, работает нормально в Windows 7 и 10.

.

Вести журнал изменений

Доступна новая версия: English 1.0.0

Не позволяйте друзьям сбрасывать журналы git в CHANGELOGs ™

Версия 0.3.0

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

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

 # История изменений
Все заметные изменения в этом проекте будут задокументированы в этом файле.

Формат основан на [Вести журнал изменений] (https: // keepachangelog.com / en / 1.0.0 /),
и этот проект придерживается [Семантического управления версиями] (https://semver.org/spec/v2.0.0.html).

## [неизданные]

## [1.0.0] - 20.06.2017
### Добавлено
- Новая визуальная идентификация от [@ tylerfortune8] (https://github.com/tylerfortune8).
- Навигация по версиям.
- Ссылки на последнюю выпущенную версию в предыдущих версиях.
- "Зачем вести журнал изменений?" раздел.
- "Кому нужен журнал изменений?" раздел.
- "Как мне сделать журнал изменений?" раздел.
- Раздел «Часто задаваемые вопросы».
- Новый подраздел «Руководящих принципов» в «Как сделать журнал изменений?».- Переводы на упрощенный и традиционный китайский с [@tianshuo] (https://github.com/tianshuo).
- Немецкий перевод из [@mpbzh] (https://github.com/mpbzh) и [@ Art4] (https://github.com/Art4).
- Итальянский перевод из [@azkidenz] (https://github.com/azkidenz).
- Шведский перевод из [@magol] (https://github.com/magol).
- Турецкий перевод из [@karalamalar] (https://github.com/karalamalar).
- Французский перевод из [@zapashcanon] (https://github.com/zapashcanon).
- Перевод на бразильский португальский из [@Webysther] (https: // github.com / Webysther).
- Польский перевод из [@amielucha] (https://github.com/amielucha) и [@ m-aciek] (https://github.com/m-aciek).
- Русский перевод из [@aishek] (https://github.com/aishek).
- Чешский перевод от [@ h5vry] (https://github.com/h5vry).
- Словацкий перевод из [@jkostolansky] (https://github.com/jkostolansky).
- Корейский перевод из [@ pierceh89] (https://github.com/pierceh89).
- Хорватский перевод из [@porx] (https://github.com/porx).
- Персидский перевод из [@Hameds] (https: // github.com / Hameds).
- Украинский перевод с сайта [@ osadchyi-s] (https://github.com/osadchyi-s).

### Изменено
- Начните использовать «журнал изменений» вместо «журнала изменений», поскольку это обычное использование.
- Начать управление версиями на основе текущей английской версии 0.3.0 в помощь
Авторы переводов постоянно обновляют информацию.
- Перепишите "Что заставляет единорогов плакать?" раздел.
- Перепишите подраздел «Игнорирование устаревания», чтобы прояснить идеал.
  сценарий.
- Улучшен подраздел "Зафиксировать изменения журнала", чтобы получить дополнительные аргументы против
  их.
- Объедините "Почему люди не могут просто использовать git log diff?" с "Журнал фиксации
  различия "
- Исправьте опечатки в переводах на упрощенный китайский и традиционный китайский.- Исправить опечатки в бразильском португальском переводе.
- Исправить опечатки в турецком переводе.
- Исправить опечатки в чешском переводе.
- Исправить опечатки в шведском переводе.
- Улучшение фразировки во французском переводе.
- Исправить словосочетание и орфографию в немецком переводе.

### Удалено
- Раздел о «журнале изменений» и «CHANGELOG».

## [0.3.0] - 03.12.2015
### Добавлено
- RU перевод от [@aishek] (https://github.com/aishek).
- перевод pt-BR из [@tallesl] (https://github.com/tallesl).
- перевод es-ES из [@ZeliosAriex] (https: // github.com / ZeliosAriex).

## [0.2.0] - 06.10.2015
### Изменено
- Удалите исключительные упоминания «открытого исходного кода», поскольку этот проект может
в равной степени приносят пользу как проектам с «открытым», так и «закрытым» кодом.

## [0.1.0] - 06.10.2015
### Добавлено
- Ответ «Стоит ли когда-нибудь переписывать журнал изменений?».

### Изменено
- Улучшить аргумент против журналов фиксации.
- Начните правильно подписываться на [SemVer] (https://semver.org).

## [0.0.8] - 17 февраля 2015 г.
### Изменено
- Обновите год, чтобы он соответствовал каждому примеру README.
- Неохотно перестаньте высмеивать только британцев, так как большая часть мира
  пишет даты странным образом.### Исправлена
- Исправить опечатки в последних изменениях README.
- Обновить устаревшую неизданную ссылку на различие.

## [0.0.7] - 16 февраля 2015 г.
### Добавлено
- Свяжите и сделайте очевидным, что формат даты - ISO 8601.

### Изменено
- Уточнен раздел «Есть ли стандартный формат журнала изменений?».

### Исправлена
- Исправлены ссылки Markdown для URL сравнения тегов со ссылками в стиле сносок.

## [0.0.6] - 12 декабря 2014 г.
### Добавлено
- Раздел README о "выдернутых" релизах.

## [0.0.5] - 09.08.2014
### Добавлено
- Ссылки Markdown на теги версий в заголовках выпусков.- Неизданный раздел для сбора невыпущенных изменений и поощрения примечания
сохранение до релизов.

## [0.0.4] - 09.08.2014
### Добавлено
- Лучшее объяснение разницы между файлом («ИЗМЕНЕНИЕ»)
и его функция «журнал изменений».

### Изменено
- Ссылайтесь на «журнал изменений» вместо «CHANGELOG» на всем сайте.
чтобы различать файл и цель файла -
регистрация изменений.

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

## [0.0.3] - 09.08.2014
### Добавлено
- "Почему это должно меня беспокоить?" раздел, в котором упоминается подкаст "Журнал изменений".

## [0.0.2] - 10.07.2014
### Добавлено
- Объяснение рекомендуемого обратного хронологического порядка выпуска.

## [0.0.1] - 31.05.2014
### Добавлено
- Этот файл CHANGELOG, надеюсь, послужит развивающимся примером
  стандартизированный проект с открытым исходным кодом CHANGELOG.
- Файл CNAME для включения личного домена GitHub Pages
- README теперь содержит ответы на общие вопросы о CHANGELOG
- Хорошие примеры и основные рекомендации, включая правильное форматирование даты.- Контрпримеры: «Что заставляет плакать единорогов?»













 

В чем смысл журнала изменений?

Чтобы пользователям и участникам было проще увидеть, какие заметные изменения были сделаны между каждым выпуском (или версией) проекта.

Почему я должен волноваться?

Потому что программные инструменты предназначены для людей. Если вам все равно, почему вы вносите свой вклад в разработку открытого кода? Несомненно, где-то в твоем очаровательном маленьком мозгу должно быть зерно (ха!) Заботы.

Я разговаривал с Адамом Стаковяком и Джеродом Санто в подкасте «Журнал изменений» (уместно, верно?) О том, почему сопровождающие и участники должны заботиться, а также о мотивах этого проекта. Если у вас есть время (1:06), это хороший способ послушать.

Что делает журнал изменений хорошим?

Рад, что вы спросили.

Хороший журнал изменений придерживается следующих принципов:

• Он создан для людей, а не для машин, поэтому удобочитаемость имеет решающее значение.
• Простая ссылка на любой раздел (следовательно, Markdown поверх обычного текста).
• Один подраздел для каждой версии.
• Список выпусков в обратном хронологическом порядке (самые новые сверху).
• Запишите все даты в формате ГГГГ-ММ-ДД . (Пример: 2012-06-02 для 2 июня 2012 г. .) Это международный, разумный и независимый от языка.
• Четко укажите, следует ли проект семантическому управлению версиями.
• Каждая версия должна:
  • Укажите дату выпуска в указанном выше формате.
  • Сгруппируйте изменения, чтобы описать их влияние на проект, следующим образом:
  • Добавлен для новых функций.
  • Изменено для изменения существующей функциональности.
  • Устарело для некогда стабильных функций, удаленных в следующих выпусках.
  • Удалено для устаревших функций, удаленных в этом выпуске.
  • Исправлено для любых исправлений ошибок.
  • Безопасность , чтобы предлагать пользователям обновиться в случае уязвимостей.

Как я могу свести к минимуму требуемые усилия?

Всегда имейте наверху раздел «Неопубликованные» для отслеживания любых изменений.

Это служит двум целям:

• Люди могут видеть, какие изменения они могут ожидать в следующих выпусках.
• Во время выпуска вам просто нужно изменить «Unreleased» на номер версии и добавить новый «Unreleased» заголовок вверху.

Что заставляет плакать единорогов?

Хорошо… давай займемся этим.

• Выгрузка разницы журналов фиксации. Только не делай этого, ты никому не помогаешь.
• Без учета устаревания. Когда люди переходят с одной версии на другую, должно быть до боли ясно, когда что-то сломается.
• Даты в региональном формате. В США люди сначала ставят месяц («06-02-2012» для 2 июня 2012 г., что означает — нет смысла ), в то время как многие люди в остальном мире пишут, что это похоже на роботов »2 июня 2012 г. «, но произносить это иначе. «2012-06-02» работает логически от наибольшего к наименьшему, не пересекается двусмысленно с другими форматами даты и является стандартом ISO.Таким образом, это рекомендуемый формат даты для журналов изменений.

Это еще не все. Помогите мне собрать эти слезы единорога, открыв вопрос или запрос на перенос.

Существует ли стандартный формат журнала изменений?

К сожалению, нет. Успокоиться. Я знаю, что вы яростно торопитесь найти эту ссылку на руководство по стилю журнала изменений GNU или на «руководство» из двух параграфов файла GNU NEWS. Руководство по стилю GNU — хорошее начало, но, к сожалению, наивно. Нет ничего плохого в том, чтобы быть наивным, но когда людям нужно руководство, оно редко помогает.Особенно, когда приходится иметь дело с множеством ситуаций и крайних случаев.

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

Как следует называть файл журнала изменений?

Ну, если вы не можете сказать из приведенного выше примера, CHANGELOG.md — лучшая конвенция на сегодняшний день.

Некоторые проекты также используют HISTORY.txt , HISTORY.md , History.md , NEWS.txt , NEWS.md , News.txt , RELEASES.txt , RELEASE .md , релизы .md и т.д.

Это лажа. Все эти имена только усложняют поиск людям.

Почему люди не могут просто использовать git log diff?

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

Как разница между хорошими комментариями и самим кодом, так и разница между журналом изменений и журналом фиксации: один описывает почему , другой как.

Может ли журнал изменений анализироваться автоматически?

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

Vandamme — это драгоценный камень Ruby, созданный командой Gemnasium, который анализирует многие (но не все) журналы изменений проектов с открытым исходным кодом.

.

No related posts.