Inetpub logs чистка windows 2012

Обновлено: 03.07.2024

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

Итак, мой вопрос: где IIS7 хранит журналы по умолчанию?

Я думаю, что это место по умолчанию для журналов доступа составляет

в противном случае проверьте в Диспетчере IIS, выберите компьютер на левой панели, а в средней панели перейдите в раздел "ведение журнала" в области IIS. Там вы увидите местоположение по умолчанию для всех сайтов (это, однако, переопределяется на всех сайтах)

вы также можете посмотреть в

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

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

перейдите на свой сайт IIS, например по умолчанию, нажмите на него, и вы увидите "Logging" справа, если ведение журнала включено:

enter image description here

откройте его, и вы увидите папку прямо там:

enter image description here

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

Если ваш сервер имеет несколько веб-сайтов, вам нужно будет знать идентификатор IIS для сайта. Простой способ получить это в IIS-просто нажать на сайты папка на левой панели. Идентификатор каждого сайта отображается на правой панели.

Как только вы знаете ID, давайте назовем его n, соответствующие журналы находятся в W3SVCn в папке IIS в папке logs. Итак, если Ваш идентификатор веб-сайта равен 4, скажем, и журналы IIS находятся в по умолчанию местоположение и журналы находятся в этой папке:

  • ответ @jishi сообщает, где журналы по умолчанию.
  • ответ @Rafid объясняет, как найти фактическое местоположение (возможно, не по умолчанию).
  • ответ @Bergius дает программный способ найти расположение папки журнала для определенного веб-сайта с учетом идентификатора без использования IIS.

100% правильный ответ для расположения файлов журнала по умолчанию.

Да, вы можете ввести это в адресную строку проводника, она будет работать.

чтобы быть на 100% уверенным, вам нужно посмотреть журнал для веб-сайта в IIS.

  1. Откройте Диспетчер IIS.
  2. выберите сайт или сервер на панели подключения,
  3. дважды щелкните журнал.
  4. расположение файлов журнала для сайта можно найти в поле Каталог

Enable HTTP Logging

гораздо проще сделать это с помощью PowerShell, например:

если вам просто нужна информация для себя и не против разбора результате в вашем мозгу :).

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

попробуйте журнал событий Windows, может быть какая-то полезная информация

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

Я думаю, что место по умолчанию для ведения журнала IIS: c:\inetpub\wwwroot\log\w3svc

date

21.12.2016

directory

PowerShell, Windows Server 2012

comments

комментария 3

Веб сервер IIS (Internet Information Services) в процессе работы генерирует довольно большое количество логов, которые пишутся в файлы журналов. Основная проблема в том, что по-умолчанию журналы IIS расположены на системном диске, и со временем файлы логов могут забить все доступное место на диске и работа сервера будет парализована. К примеру, в моем случае на Exchange Server 2013 с почти 1000 ящиков, IIS генерирует за день лог-файл порядком 200 Мб. Таким образом, за год, файлы логов IIS будут занимать 70 Гб дискового пространства. Можно ли как-то управлять эти процессом?

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

В первую очередь администратор должен в принципе решить, нужны ли вообще логи, которые генерирует IIS. Если вопрос отрицательный – ведение журналов логов можно отключить в настройках сайта в консоли Internet Information Services (IIS) Manager в разделе Logging. В некоторых случая также применим перенос файлов журналов с системного диска на диск с данными/выделенный диск. Для этого в том же разделе достаточно изменить путь к каталогу LogFiles.

Так по-умолчанию, в Windows Server 2003 логи IIS хранятся в папке %windir%\system32\LogFiles\ и в Windows Server 2008 / 2012 /R2 в папке %SystemDrive%\inetpub\logs\LogFiles\.


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


Если попытаться открыть каталог %SystemDrive%\inetpub\logs\LogFiles, подтверждая назначение необходимых разрешений (или запустить проводник с правами администратора), можно увидеть, что на самом деле размер папки с логами довольно велик.


Как правило, можно безопасно удалить все файлы логов старше 3-7 дней. Это можно сделать вручную (не самый лучший вариант), либо автоматически с помощью скрипт PowerShell который будет удалять старые лог файлы по расписанию.

Простой PowerShell скрипт, который будет рекурсивно удалять файлы с расширением *.log из каталога C:\inetpub\logs может быть таким:

gci ‘C:\inetpub\logs -Include ‘*.log’ -Recurse | ? LastWriteTime -LT (Get-Date).AddDays(-7) | Remove-Item

Для автоматического запуска скрипта можно создать такое задание в планировщике (Task Scheduler):

Совет. Еще один способ «быстро» уменьшить размер логов, когда удалять их по каким-то причинам нельзя – включить NTFS сжатие на каталоге с логами. Т.к. логи представляют собой простые текстовые файлы, жмутся они довольно сильно (в 4 -5 раз). Чтобы включить NTFS компрессию, откройте свойства папки с логами и нажмите на кнопку Advanced. Отметьте галку Compress contents to save disk space и дважды нажмите OK.

Логи IIS

Веб-сервер IIS в процессе своей работы генерирует достаточно большие объемы log-файлов. Все бы ничего, но по умолчанию логи IIS располагаются на системном диске , которому обычно не предоставляют большой объем. Хорошо, если у вас виртуальная машина и вы можете просто не обращать внимание на нехватку диска C:\, увеличивая его объем по необходимости, благо функционал виртуальных машин Hyper-V второго поколения позволяет увеличивать размер даже системного диска без выключения сервера, прямо налету. А если у вас такой возможности нет? В таком случае разрастание логов может стать для вас серьезной проблемой.

В статье я расскажу как обращаться с log-файлами IIS и автоматизировать процесс удаления.

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.

Логи IIS

По умолчанию логи IIS располагаются в каталоге %SystemDrive%\inetpub\logs\LogFiles. Сигналом для их очистки может служить истощающееся быстрыми темпами свободное место системного диска. В этом случае системные администраторы начинают искать что же занимает столько места и благополучно пропускают папку inetpub, поскольку по умолчанию она практически ничего не весит:

Логи IIS - очистка 01

Но почему? Дело в том, что изначально вы не имеете разрешений на вложенные папки, следовательно не можете увидеть их реальный объем:

Логи IIS - очистка 02

Попробуйте зайти в каждую подпапку каталога %SystemDrive%\inetpub\logs\LogFiles, соглашаясь с назначением необходимых разрешений и в итоге увидите, что реальный объем папок не так уж и мал:

Логи IIS - очистка 03

Разумеется у меня приведены в пример скриншоты с тестового сервера. Объем логов серверов в продакшене может достигать десятков и сотен гигабайт совершенно спокойно.

Итак, проблема найдена, пора заняться очисткой. Теоретически её можно проводить и вручную, но в этом нет никакого смысла и проще все сделать скриптами, в некоторых случаях достаточно даже одной команды PowerShell. В одной из статей по Exchange 2013 (см. Очистка папки Logging Exchange 2013) я уже рассматривал вопрос автоматизации процесса очистки логов, но не помешает напомнить о нем и в этой статье.

Команда для очистки log-файлов в нашем случае будет выглядеть следующим образом:


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

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

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

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

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

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



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

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



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

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

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

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

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



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

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



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

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

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

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

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

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



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

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

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

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

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

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

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



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

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

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

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

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

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



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

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

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

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



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



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

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

Благодаря этой возможности для облегчения работы существует несколько утилит, представляющих из себя графическую оболочку для 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.

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


Аудит ИБ

Как удалить записи событий системных журналах

В область кибербезопасности чрезвычайно быстро растет потребность в специалистах по информационной безопасноти в целях защиты организаций от киберугроз и противодействию злоумышленникам. Кибератака может быть чем угодно: от фишингового письма до заражения вредоносным ПО, атакой с помощью программ-вымогателей(шифровальщиков) и т.д. Международные организации по кибербезопасности и органы сертификации, такие как EC-Council и GIAC, подчеркивают роль в компьютерной криминалистики в цифровом мире. В рамках расследованиях необходимо определить, что произошло, как произошла атака, определить возможных исполнителей, а также прояснить многие другие детали, которые могут помочь при обвинение в суде.

Типы журналов и их расположение

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

Журналы DHCP-сервера

В этих журналах ведется учет присвоения IP-адресов в сети. В этом журнале хранятся все события при взаимодействии между потенциальным DHCP-клиентом и DHCP-сервером. Наибольший интерес здесь представляют MAC-адресса клиентов, которые будут занесены в соответсвующий журнал событий.
Ниже приведены местоположения журналов DHCP-сервера:
Журналы DHCP хранятся в каталоге % SystemRoot% \ System32 \ dhcp для ОС Windows.
В Linux для просмотра журналов DHCP мы можем использовать команду

События Syslog

Пакетный анализ

Далее,проводя исследования сети, эксперты проводят анализ пакетов, наблюдая за любыми аномалиями в интересующем сегменте сети. Анализ пакетов позволяет определить следующее:
Источник атаки
Загруженые и скачаные файлы
Тип трафика в сети
Время атаки
Извлеченные артефакты, например файлы
URL-адреса и домены
Атакованный хост
Данные телеметрии

Журналы веб-сервера

Журналы базы данных

HKLM \ System \ ControlSet00x \ Services \ EventLog

Чтобы просмотреть список имён доступных журналов событий в Windows 10, используйте команду


Кроме того, использование команды wevtutil gl <имя журнала> представит информацию о конфигурации для выбранного журнала:


Стоит отметить, что сами системные журналы Windows хранятся в C:\Windows\System32\winevt \Logs в локальной системе:


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

Очистка журналов в Windows

В операционной системе Windows средство просмотра событий представляет собой приложение, которое объединяет журналы приложений, безопасности, установки и системы на единой информационной панели. Она располагается в:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\Просмотрщик событий

Также для открытия средства просмотра событий в Windows достаточно ввести сочение клавиш Win + R , и в окне «Выполнить» ввести eventvwr.msc и нажать OK.
В окне «Просмотр событий» журналы можно очистить, просто выбрав функцию «Очистить журнал» кнопкой на панели «Действия». Чтобы очистить журналы для определенной категории, например всех журналов, которые находятся в группе «Приложение», просто щелкните правой кнопкой мыши имя группы и выберите «Очистить журнал».


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

Использование PowerShell для очистки журналов в Windows

Теперь рассмотрим несколько комманд для очистки журналов.

1.Для очиски всех журналов событий:


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



Использование параметра Get-Help, за которым следует командлет Clear-EventLog, предоставит вам дополнительные параметры:


Далее рассмотрим использование командной строки для очистки журналов.

Использование командной строки для очистки журналов в Windows

Теперь рассмотрим использование командной строки для очистки журналов в ОС Windows:

1 Очистка отдельных журналов
Ранее мы использовали команду wevtutil el в командной строке Windows для просмотра списка типов / категорий журналов. Мы можем использовать wevtutil cl, за которым следует конкретный журнал, чтобы стереть / очистить записи в категории журнала:


Кроме того,можно использовать синтаксис clear-log вместо cl:


2.Очистка всех журналов одним скриптом

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


Использование Meterpreter для очистки журналов Windows


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

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