Логи iis где лежат: Как парсить (отфильтровать) логи IIS (веб сервера) вручную.

Как парсить (отфильтровать) логи IIS (веб сервера) вручную.

Как пропарсить (отфильтровать) логи IIS (веб сервера).

Для начала нужно узнать где лежат логи. Для IIS 6 логи обычно лежат по пути «C:\WINDOWS\system32\LogFiles\», все зависит от настроек, но по умолчанию логи именно там. Пуск (Start) — Мой компюьтер (My computer) — Управление (Manage) — Сервисы и приложения (Service and Applications) — Упраеление Веб сервером (Internet Information Services IIS manager) —  Веб сайты (Web Sites) — Свойства (Properties).  Откроется (Default Web Site Propirties):

Далее нажать — Свойства (Properties) напротив Активного формата лога (Active log format). В строке Директория файлов лога (Log file directory) указан нужный нам путь. Те в этой папке хранятся логи нашего веб сервера.

Можно скопировать данный путь и перейти в данную папку. Выбрать за нужную дату файлы, они хранятся в виде текстовых файлов с именами: exYYMMDDNN.log, где YY — год,  MM-месяц, DD-день.

Копируем нужные нам файлы в отдельную директорию. Создаем в этой же директории файл PPP.bat, со следующим содержимым:

find /I «name_site» *.* | find » POST » | find » 200 » >> resume.txt.

где, name_site — имя сайта или приложения, если он один нужно написать его название, например /site.ru

200 — статус успешно обработанного запроса. если нужно количество другого типа запросов например недоступности, то нужно проставить соответствующий статус, например 300, 500.

Скрипт сделает следующую работу: в каждом файле будет искать строку с именем сайта и соответствующим ему статусом, в конечном результате создастся в той же директории файл resume.txt, с  размером сообщений и суммарным объёмом пройденного трафика.

Далее необходимо файл resume.txt, обработать в exel. Запускаем exel, переходим: Данные — Из текста:Выбираем файл resume.txt и нажимаем импорт.Открывается мастер импорта: выбираем с разделителями. Далее. Убираем все галки, кроме пробела. Далее.Дата: ГМД, готово.

Для получения статистики к последней колонке применяются формулы:
=SUM(№ первой ячейки:№ последней ячейки) сумма
=MIN(№ первой ячейки:№ последней ячейки) мин
=MAX(№ первой ячейки:№ последней ячейки) макс=AVERAGE(№ первой ячейки:№ последней ячейки) среднее.

Результат имеет примерно такой вид:

Вконтакте

Одноклассники

Мой мир

Facebook

E-mail

Возможности журналирования и анализа логов в IIS 8.5

В новой версии Internet Information Services 8.5, представленной в качестве роли веб сервера в Microsoft Windows Server 2012 R2, появилась новая возможность логирования. IIS теперь может писать HTTP-логи в особый журнал трассировки через службу трассировки событий Windows (Event Tracing for Windows — ETW). Благодаря механизму Event Tracing for Windows  в IIS 8.5 появилась возможность отслеживать события на веб сервере в реальном времени, что крайне полезно при отладке веб-приложений и поиске неисправностей.

В предыдущих версиях IIS логи веб-сервера записывались в отдельные лог-файлы. Основной недостаток данного механизма – кэширования логов в оперативной памяти. Логи из кэша записываются (сбрасываются) на диск каждую минуты или по достижению объема 64Кб. Это значительно усложняло онлайн-траблшутинг в IIS, т.к. высока вероятность того, что событие, появление которого вы ожидаете, произошло, но информация о нем пока просто не записалась в лог файл, и, соответственно, вы его не сразу не увидите.

Справка. Event Tracing for Windows (ETW) – высокопроизводительная система журналирования, представленная еще в Windows Vista. Системные компоненты и пользовательские приложения при помощи специального  API могут отправлять этой системе сообщения о своем состоянии (логи). Система ETW генерирует сравнительно небольшую нагрузку, так, например запись информации о 10000 событий за секунду через службу трассировки займет всего порядка 3% процессорных ресурсов. Система  ETW не заменяет обычный журнал событий и служит обычно для непродолжительной по времени диагностики работы приложений или системы.

В этой статье мы покажем, как в IIS 8.5 задействовать службу трассировки событий Windows (ETW) и как проанализировать полученные логи с помощью Microsoft Message Analyzer.

По умолчанию IIS 8.5 записывает логи в обычные тестовые файлы. Чтобы включить логирование через ETW, нужно в панели управления IIS (Internet Information Services Manager), выбрать имя сервера и в правой панели щелкнуть по значку Logging.

Примечание. Опция Logging будет доступна только при установленном компоненте IIS: HTTP Logging (Web Server -> Health and Diagnostics -> HTTP Logging).

В окне настройки параметров журналирования в разделе Log Event Destination выберете метод ведения журнала, переключившись со стандартного Log file only на ETW event only. Обратите внимание, что можно включить ETW и стандартное журналирование  IIS одновременно (Both log file and ETW event). Сохраним изменения. Сразу после этого логи веб сервера IIS начнут писаться через службу трассировки событий Windows.

Для просмотра и анализа логов IIS в журналах ETW воспользуемся бесплатным инструментом Microsoft Message Analyzer, который можно скачать с сайта Microsoft по этой ссылке: _http://www.microsoft.com/en-us/download/details.aspx?id=40308

Во время первого запуска Microsoft Message Analyzer спросит, хотите ли вы обновить элементы на стартовом экране. Выберите желаемое действие.

В открывшемся окне Message Analyzer настроим доступ к логам IIS ETW. Для этого щелкните по ссылке Capture/Trace в левой колонке и укажите имя трассировки.

В разделе Trace Scenario Configuration в поле Add Provider введите IIS и из появившегося выпадающего списка выберите Microsoft-Windows-IIS-Logging.

После того, как мы подключились к нужному провайдеру ETW, можно начать просмотр ( и сбор) событий, нажав кнопку Start With.

Собранные данные будут отображены в виде таблицы (если эта опция была указана при запуске).

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

Для этого в расширенном описании нужного события щелкнем по полю S_sitename и выберем Add Ssitename To Filter (добавить имя сайта в фильтр).

В окне фильтров появится сгенерированный текст кода фильтра. Если нажать кнопку Apply Filter, в окне журнала останутся только данные, которые относятся к указанному нами сайту.

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

Итак, в этом небольшом обзоре мы разобрались с новыми возможностями анализа и поиска неисправностей на веб сервере IIS, с помощью журналирования событий веб-сервера через систему ETW. Также мы показали как можно анализировать полученных данных с помощью Microsoft Message Analyzer.

Изменение директории расположения лог-файлов в IIS7

Сервер Exchange Server 2010 с ролью клиентского доступа (Client Access server) генерирует с помощью IIS большое количество логов о клиентском трафике, подобном OWA и ActiveSync.

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

Откройте IIS Manager из Administrative Tools и выберите Default Web Site.

Нажмите дважды по иконке Logging.

Введите путь к новой директории, которую вы хотите использовать или нажмите Browse и выберите её.

После этого нажмите Apply.

Новая директория будет создана (если вы не создали её вручную) когда будут сгенерированы новые записи в лог-файлы на данном сервере.

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

Также вы можете выполнить эти действия с помощью Powershell. Запустите Powershell и выполните следующие команды:

PS C:\> Import-Module WebAdministration
PS C:\> Set-ItemProperty 'IIS:\Sites\Default Web Site' -name logfile.directory "D:\IISLogs"

Полезная информация

Качественная пластика ушей в велоколепной клинике «Медикал Клаб». Нет нужды жить лопоухим если сегодня это можно исправить очень быстро и недорого.

Недавнор потребовалось заказать перевозку гостей из пункта А в пункт Б. Лучшие условия я нашел в автотранспортная компании «ГОСТИНН» — аренда и заказ автобусов. Рекомендую пользоваться услугами данной компании.

Еще записи по теме

PowerShell — Настраиваем очистку логов IIS

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

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

Param (
    #период в днях, старше которого файл считается пригодным к удалению
    [int]$Period = 10 , 
    
    #каталог для просмотра  
    [String]$PATH = "C:\inetpub\logs\LogFiles" ,
    
    #включать ли вложенные каталоги
    [bool]$recurse = $true
    )
    
filter Get-OldFiles
{
    if    
       (($_.Attributes -ne "Directory") `
            -and `
            (([DateTime]::Now.Subtract($_.CreationTime)).Days -gt $Period)) 
        {return $_ }
}

if ($recurse) 
        {dir -path $PATH -recurse  | Get-OldFiles -Period $Period | Remove-Item -recurse -force}
else
        {dir -path $PATH | Get-OldFiles -Period $Period | Remove-Item -force}

Скрипт сохраняем на веб-сервере по полному пути, например
C:\Tools\Scripts\Delete-Old-IIS-Log-Files.ps1

В Планировщике заданий Windows (Task Scheduler) создаём задание на периодический запуск данного скрипта командой:

powershell.exe -NoProfile -command "C:\Tools\Scripts\Delete-Old-IIS-Log-Files.ps1"

В сети может быть большое количество серверов, на которых работают сайты на базе IIS, однако на всех таких серверах интенсивность записи в логи разная. Чтобы понять, на какие веб-серверы имеет смысл “прикручивать” скрипт удаления старых логов IIS, а на какие нет, воспользуемся ещё одним PS-скриптом. С помощью этого скрипта мы получим список серверных системы из каталога Active Directory и проверим на каждом из серверов размер каталога логов IIS (по умолчанию расположен в C:\inetpub\logs) при условии его наличия.

Import-Module ActiveDirectory

$TestFolder = "\C$\inetpub\logs"
$OU =  "OU=AllComputers,DC=holding,DC=com"
$Filter = "(&(objectClass=computer)(!description=*cluster*)(operatingSystem=*Windows Server*)(!userAccountControl:1.2.840.113556.1.4.803:=2))"

$Servers = Get-ADComputer -SearchBase $OU -ResultSetSize $null -LDAPFilter $Filter
ForEach ($Server in $Servers){

    $ServerName = $Server.DNSHostName
    ping.exe $ServerName -n 1 | out-null; 
    If ($LASTEXITCODE -eq 0){
        
        # Сервер доступен, проверяем наличие папки...

        $RemotePath = "\\" + $ServerName + $TestFolder
        If(Test-Path -Path $RemotePath){
            $size = (Get-ChildItem $RemotePath -recurse | Measure-Object -property length -sum)
            "$ServerName - " + "{0:N2}" -f ($size.sum / 1MB) + " MB"
            }
        }
    Else{
        Write-Host "Сервер $ServerName недоступен" -ForegroundColor Red
    }
}

Архив со скриптами и готовым экспортированным заданием Планировщика заданий (импорт задания проверялся на системах Windows Server 2012 R2) можно загрузить по ссылке.

Поделиться ссылкой на эту запись:

Похожее

Поддержание достоверности лог-файлов IIS

В настоящее время многие веб-администраторы сталкиваются с серьезными вторжениями в свои серверы, которые часто заканчиваются судебными исками. Первым очевидным свидетельством для обнаружения злоумышленников, конечно, являются лог-файлы веб-сервера. Однако в этом случае сразу же возникает вопрос о том, возможно ли использовать IIS лог-файлы в качестве свидетельских показаний в суде. Может ли представитель защиты заявить, что записи в этих файлах недостаточно достоверны и поэтому не могут считаться свидетельским показанием?
Недавно в рамках одного криминального расследования я занимался исследованием серьезного вторжения. Злоумышленник проник в IIS-сервер, загрузил свои программные инструменты, с помощью которых вторгся во внутреннюю базу данных компании. Мы приблизительно знали, когда это случилось, но было неизвестно, через какой из нескольких сотен веб-сайтов на дюжине серверов произошло вторжение.
Перекопав сотни лог-файлов веб-серверов, я натолкнулся на один лог-файл, в котором среди тысяч отметок о вхождениях имелась одна пустая строчка. Я проверил последнее изменение даты этого файла и обнаружил, что она была изменена спустя два дня после того, как лог-файл был закрыт. Сотни мегабайтов показаний лог-файла внезапно стали бесполезными из-за единственной пустой строчки. Поскольку лог-файлы хранились на том же самом сервере, через который произошло вторжение, злоумышленник, возможно, легко удалил отметку о своем вхождении или, хуже того, заменил ее ложной записью. Изменение всего лишь одного лог-файла заставляет подвергнуть сомнению истинность всех лог-файлов на этом сервере.
Для доказательства подлинности ваших лог-файлов необходимо привести убедительные аргументы, так как только в этом случае эти лог-файлы могут быть приняты судом в качестве свидетельства. Поэтому необходимо предпринять меры защиты ваших лог-файлов, которые бы гарантировали их точность, подлинность, а так же возможность обращения к IIS лог-файлам. Хотя, следует отметить, что существует множество юридических сложностей, и в каждом конкретном случае необходимо найти верное решение проблемы. Ниже приведены некоторые советы, которые должны увеличить достоверность ваших IIS лог-файлов.

точность лог-файла

Понятие точность применительно к лог-файлу означает, что вы можете доказать точность данных этого файла. Даже самая небольшая неточность может поставить под сомнение истинность данных. Следующие действия помогают вам обеспечить точность данных.
Регистрируйте все. Настройте свои IIS лог-файлы так, чтобы в них записывались все действия. Хотя некоторые администраторы не видят большой ценности в хранении этой дополнительной информации, тем не менее, каждая такая запись имеет значение, если мы производим расследование. Однажды, проверяя лог-файлы после вторжения, я по некоторым признакам обнаружил, что нападавший создал файлы в директории C:\ \WINNT. Однако я не мог найти эти файлы на жестком диске. Просмотрев более внимательно лог-файлы, я заметил, что имя сервера не соответствовало имени, зарегистрированному в IIS лог-файлах. Оказалось, что компания недавно перевела веб-сайт на новый сервер. Проверив старый сервер, я немедленно нашел нужные файлы. Без зарегистрированного имени хоста я не смог бы сделать это.
Кроме того, информация о посетителях сети помогает устанавливать, что нападение исходит от определенной компьютерной системы или зарегистрированного пользователя. Например, предположим, ответчик утверждает, что хакер вторгся в его компьютер и установил анонимный прокси сервер, а затем использовал его для нападения на другие системы. Как доказать, что трафик прибыл от веб-браузера некоторого пользователя или нападение исходило от кого-то еще? Хотя не всегда это можно доказать, но чем больше информации вы соберете, тем больше шансов разобраться с данным конкретным случаем.
Синхронизируйте время. Синхронизируйте ваши IIS-серверы с внешним источником времени, пользуясь службой времени Windows. Если вы используете домен, служба времени будет автоматически синхронизирована с контроллером домена. На автономном сервере вы можете синхронизировать время следующим образом:

Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\
Setting: Type
Type: REG_SZ
Value: NTP
Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\
Setting: NtpServer
Type: REG_SZ
Value: tock.usno.navy.mil (см. http://tycho.usno.navy.mil/ntp.html для списка NTP-серверов.)
Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\
Setting: Period
Type: REG_SZ
Value: 24 (количество синхронизаций в день. Если 24, то синхронизация будет производиться каждый час. Можно устанавливать и меньшее количество.)

Другая проблема, связанная со временем, заключается в том, что IIS записывает лог-файлы, используя единое время. Предполагается, что это помогает синхронизации, когда сервер обслуживает зоны во многих часовых поясах. Однако Windows вычисляет единое время, изменяя системное время на поясную поправку. Единственный способ быть уверенным в правильности установки единого времени — правильная установка местного времени.
Существует способ, позволяющий проверить то, что IIS лог-файлы используют местное время. Вы можете проверить установку часового пояса сервера, просмотрев первые вхождения в лог-файле. Если на вашем сервере поясная поправка равна -0600, то первые вхождения (за день) в лог-файле должны появиться около 18:00 (00:00 — 06:00 = 18:00). Поскольку в едином времени не учитываются переходы на летнее время, вы должны также обращать внимание на дату. Например, поясная поправка — 6:00 через полгода будет равна -5:00.
Используйте множественные датчики. Трудно опровергнуть регистрацию вхождения, если оно записано двумя различными устройствами. Комбинируя лог-файлы от нескольких устройств, вы усиливаете ценность каждого из них. Лог-файлы Firewall и IDS и даже столь простые, как логи TCPDump, могут помочь доказать, что с данного IP-адреса происходит атака на определенный сервер в определенное время.

подлинность лог-файла

Лог-файлы называются подлинными, если можно доказать, что они не были изменены со времени первоначальной записи. IIS лог-файлы являются обычными текстовыми файлами, которые легко изменить. Дата файла и отметки времени также могут легко быть изменены. В случае недоверия IIS лог-файлы не могут считаться подлинными, но при помощи следующих действий, вы можете исправить эту ситуацию.
Переместите лог-файлы. Чтобы гарантировать подлинность, переместите IIS лог-файлы из веб-сервера. Если сервер был компрометирован, вы должны предполагать, что лог-файлы также, возможно, были скомпрометированы. Переместите лог-файлы на мастер-сервер, после чего, как можно быстрее, переместите их (в автономном режиме) на ленту, компакт-диск, или WORM-device.
Подписи, кодирование и контрольные суммы. Единственный способ, абсолютно гарантирующий, что лог-файл не был изменен, — это подписать и закодировать лог-файл при помощи PGP или другой схемы кодирования. Подписи файла полезны, потому что, если отдельный лог-файл испорчен, другие файлы истинны. Вы можете также использовать инструмент типа Fsum (http://www.slavasoft.com/fsum/), чтобы быстро сгенерировать MD5-таблицы для файлов. Храните подписи и хэш-таблицы вместе с лог-файлами, но также храните и защищенную копию в отдельном месте.
Обратите внимание, что, если вы используете автоматизированный процесс подписывания файлов, вы должны всегда иметь собственноручную подпись администратора, которому доверяете.
При шифровке файлов, вы должны иметь в виду воздействие на созданные, измененные, и входные данные, которое может произойти. Вы можете сделать запись этих данных в отдельном месте, используя утилиту типа Fdir (http://www.roninsg.com/fdir.zip).
Работайте с копиями. При выполнении анализа лог-файла, никогда не работайте с оригинальными файлами. Делайте копии перед выполнением любой последующей обработки или анализа. Создание уверенности, что оригинальные лог-файлы не затронуты, помогает вам гарантировать, что они все еще подлинны. Если вы используете лог-файлы в качестве свидетельских показаний, вы должны представить оригинальные файлы в их первоначальном виде. Заметим, что в Федеральном законе Соединенных Штатов о свидетельских показаниях записано: точная распечатка также может рассматриваться, как свидетельское показание (см. Federal Rules of Evidence 1001(3) на http://www.law.cornell.edu/rules/fre/).
Следите за целостностью системы. Вы всегда должны проверять сервисные пакеты и hotfixes, чтобы гарантировать, что ваши системные файлы в порядке. Вы должны также проверять все изменения в бинарных файлах вашей директории WINNT. Если злоумышленник способен изменить системные файлы, которые делают запись лог-файлов, то лог-файлы не могут являться свидетельским показанием.

контроль доступа

Как только лог-файл создан, важно предохранить его от возможности проникновения и проверять все законные и незаконные доступы. Если вы должным образом обеспечиваете и проверяете лог-файл, пользуясь NTFS-разрешениями, вы имеете документальное свидетельство, помогающее установить его достоверность.
Ограничьте доступ к файлу. Лог-файл должен иногда разрешать доступ, чтобы IIS мог записывать в файл. Но после того, как лог-файл закрыт /* имеется в виду, по всей видимости, «закончен», например в результате ежедневной ротации — прим. ред. */, ни у кого не должно быть разрешения на изменение содержание файла. Вы можете использовать список команд для блокирования разрешений и проверок после закрытия лог-файла. Кроме того, когда вы перемещаете лог-файлы, убедитесь, что NTFS-разрешения правильно установлены в новом месте.
Цепь охраны. Когда вы перемещаете лог-файлы с сервера на автономное устройство, вы должны сохранить путь следования вашего файла. Это может быть сделано с помощью технических или нетехнических методов. Например, один мой клиент опечатывал свои ленты с резервными копиями и использовал специальный лэйбл для записи физического движения ленты. Прослеживание охраны свидетельств особенно важно при восстановлении содержания резервных копий в криминальном расследовании.
Имейте в виду, что каждодневный процесс сбора лог-файлов однажды может стать частью сбора свидетельских показаний в криминальном расследовании. Вы всегда должны рассматривать ваш IIS веб-сервер как место возможного преступления и поэтому содержите свои лог-файлы так, чтобы они могли использоваться в качестве свидетельских показаний.
В мире имеется множество законов. В современной юридической практике лог-файлы часто рассматривают всего лишь как деловые отчеты. Если вы хотите, чтобы суд принял лог-файлы в качестве свидетельских показаний, то необходимо следовать некоторым правилам, чтобы гарантировать их достоверность. Не всегда есть четкое определение того, что является допустимым, а что является достоверным. Но, как и в случае со свидетелями суда, эти понятия часто сводятся к правдоподобности. Чем больше у вас зарегистрированных свидетельств, тем более правдоподобны ваши IIS лог-файлы.
Конечно, ваши местные законы могут различаться, и ваш адвокат может иметь другое мнение о том, что делает лог-файл достоверным. Обсудите эти проблемы с вашим адвокатом, и установите процесс, который будет гарантировать точность, подлинность, и управляемый доступ к вашим IIS лог-файлам.

Марк Бернетт

Сетевые решения. Статья была опубликована в номере 04 за 2003 год в рубрике save ass…

Автоматическая очистка логов IIS с помощью PowerShell

Веб сервер 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):

1. Запустите Task Scheduler
2. В правой панели Action щелкните по Create Basic Task
3. Укажите имя задания: CleanIISLog
4. Настроим задание на еженедельный запуск по субботам
5. Запускаемая программа: powershell.exe
6. Аргументы: —NoProfile -command «gci ‘C:\inetpub\logs’ -Include ‘*.log’ -Recurse | ? LastWriteTime -LT (Get-Date).AddDays(-7) | Remove-Item»
7. Теперь откройте свойства созданного задания
8. Укажите, что задание будет запускаться из-под Системы (NT AUTHORITY\System) и поставьте чекбокс Run with highest privileges
9. Протестируйте задание, щелкнув по нему ПКМ и выбрав Run
10. Убедитесь, что все лог файлы старше 7 дней автоматически удалены

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

Поддержание Достоверности IIS Лог-Файлов

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

Марк Бернетт <mailto:[email protected]>

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

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

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

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

 Точность лог-файла

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

Регистрируйте всё. Настройте свои IIS лог-файлы так, чтобы в них
записывались все действия. Хотя некоторые администраторы не видят большой
ценности в хранении этой дополнительной информации, тем не менее, каждая такая
запись имеет  значение, если мы производим расследование. Однажды, проверяя
лог-файлы после вторжения, я по некоторым признакам обнаружил, что нападавший
создал файлы в директории C:\ \WINNT. Однако я не мог определить местонахождение
этих файлов на жестком диске. Просмотрев более внимательно лог-файлы, я заметил,
что имя сервера не соответствовало имени, зарегистрированному в IIS лог-файлах.
Оказалось, что компания недавно перевела веб-сайт на новый сервер. Проверив
старый сервер, я немедленно нашел нужные файлы. Без зарегистрированного имени
хоста я не смог бы сделать это.

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

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

Key:
HKLM\SYSTEM\CurrentControlSet|Services\W32Time\Parameters\

Setting: Type

Type: REG_SZ

Value: NTP

Key: HKLM\SYSTEM\CurrentControlSet|Services\W32Time\Parameters\

Setting: NtpServer

Type: REG_SZ

Value: tock.usno.navy.mil (see
<http://tycho.usno.navy.mil/ntp.html> для списка NTP серверов.)

Key: HKLM\SYSTEM\CurrentControlSet|Services\W32Time\Parameters\

Setting: Period

Type: REG_SZ

Value: 24 (количество синхронизаций в день. Если 24, то
синхронизация будет производиться каждый час. Можно устанавливать меньшее
количество.)

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

Существует  способ, позволяющий проверить то, что IIS лог-файлы используют
местное время. Вы можете проверить установку часового пояса сервера, просмотрев
первые вхождения в лог-файле. Если на вашем сервере поясная поправка равна
-0600, то первые вхождения (за день) в лог-файле должны появиться около 18:00
(00:00 — 06:00 = 18:00). Поскольку в едином времени не учитываются переходы на
летнее время, Вы должны также обращать внимание на дату. Например, поясная
поправка  — 6:00 через полгода будет равна -5:00.

Используйте множественные датчики. Трудно опровергнуть регистрацию
вхождения, если оно записано двумя различными устройствами. Комбинируя лог-файлы
от нескольких устройств, Вы усиливаете ценность каждого из них. Лог-файлы
Firewall и IDS и даже столь же простые, как TCPDump могут помочь доказать, что с
данного IP адреса происходит атака на определенный сервер в определенное время. 

Избегайте пропускать лог-файлы. Одна из проблем IIS лог-файлов состоит
в том, что, если сервер не атакуется в течение 24 часов, то лог-файлы не
создаются. А когда лог-файлов нет, невозможно  узнать, подвергался ли сервер
атаке (например, работал в автономном режиме в течение дня) или лог-файл был
удален. Чтобы избежать возникновения этой проблемы, я предпочитаю организовывать
несколько запланированных атак каждый день. Так как в этом случае я могу  быть
уверенным, что лог-файл всегда создается.

Для этого, я использую Graburl, который Вы можете найти на
<http://www.kiraly.com/software/utilities/graburl/>

Используя планировщика задач (Task Scheduler), я организовываю две атаки на
сервер сети: одну от своего хоста, а другую — от внешнего, при помощи простой
команды:

Graburl.exe www.example.com

Причина того, что требуются две атаки, состоит в следующем: первая атака со
своего хоста проверяет, что сервер работает, а вторая проверяет, что сервер
доступен из Интернета. Кроме того, вторая атака также проверяет синхронизацию
времени. Если вторая атака запланирована в 1:00, AM каждый день, соответствующие
вхождения в лог-файле должны всегда происходить в 1:00 AM. В общем,
запланированные атаки помогают доказывать, что механизм лог-файлов работает
должным образом.

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

Подлинность лог-файла

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

Переместите лог-файлы. Чтобы гарантировать подлинность, переместите
IIS лог-файлы  из Веб-сервера. Если сервер был компрометирован, Вы должны
предполагать, что лог-файлы также, возможно, были скомпрометированы. Переместите
лог-файлы на мастер-сервер, после чего, как можно быстрее, переместите их (в
автономном режиме) на ленту, компакт-диск, или WORM device.

Подписи, кодирование и контрольные суммы. Единственный способ,
абсолютно гарантирующий, что лог- файл не был изменен, — это подписать и
закодировать лог-файл при помощи PGP или другой схемы кодирования. Подписи файла
полезны, потому что, если отдельный лог-файл испорчен, другие файлы истинны. Вы
можете также использовать инструмент типа Fsum
<http://www.slavasoft.com/fsum/>, чтобы быстро сгенерировать MD5 —
таблицы для файлов. Храните подписи и хэш-таблицы вместе с лог-файлами, но также
храните и защищенную копию в отдельном месте.

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

При шифровке файлов, Вы должны иметь в виду воздействие на созданные,
измененные, и входные данные, которое может произойти. Вы можете сделать запись
этих данных в отдельном месте, используя утилиту типа Fdir
<http://www.roninsg.com/fdir.zip>.

Работайте с копиями. При выполнении анализа лог-файла, никогда не
работайте с оригинальными файлами. Делайте копии перед выполнением любой
последующей обработки или анализа. Создание уверенности, что оригинальные
лог-файлы не затронуты, помогает Вам гарантировать, что они все еще подлинны.
Если Вы используете лог-файлы в качестве свидетельских показаний, Вы должны
представить оригинальные файлы в их первоначальном виде. Заметим, что в
Федеральном законе  Соединенных Штатов  о свидетельских показаниях записано:
точная распечатка также может рассматриваться, как свидетельское показание (см. 
Federal Rules of Evidence 1001(3)
 <http://www.law.cornell.edu/rules/fre/>).

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

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

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

Контроль доступа

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

Ограничьте доступ к файлу.  Лог-файл должен иногда разрешать доступ,
чтобы  IIS мог записывать в файл. Но после того, как лог-файл закрыт, ни у кого
не должно быть  разрешения на изменение содержание файла. Вы можете использовать
список команд для блокирования разрешений и проверок после  закрытия лог-файла.
Кроме того, когда Вы перемещаете лог-файлы, убедитесь, что NTFS разрешения
правильно установлены в новом месте.

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

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

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

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

Управление хранилищем файлов журнала IIS

• 30.05.2014
• На чтение 9 минут

В этой статье

Джим ван де Эрве

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

Обзор

Файлы журнала, создаваемые IIS, могут со временем занять большой объем дискового пространства. Журналы потенциально могут заполнить весь жесткий диск. Чтобы смягчить эту проблему, многие пользователи полностью отключают ведение журнала. К счастью, этому есть альтернативы, например:

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

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

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

Включить сжатие папок

Файлы журнала IIS сжимаются примерно до 2% от исходного размера. Включите сжатие файла журнала следующим образом. Для выполнения этой процедуры вы должны быть администратором.

1. Щелкните значок File Manager на панели значков.
2. Перейдите в папку, содержащую файлы журнала IIS (по умолчанию % SystemDrive% \ inetpub \ logs \ LogFiles ).
3. Щелкните папку правой кнопкой мыши и выберите Свойства .
4. На вкладке Общие страницы Свойства щелкните Дополнительно .
5. Щелкните Сжать содержимое для экономии места на диске , а затем щелкните ОК .
6. Щелкните Применить , а затем выберите, следует ли сжимать только папку или папку, ее подпапки и файлы.
7. Щелкните ОК . Убедитесь, что содержимое папки сжато. Имя папки и имя каждого файла должны быть окрашены в синий цвет, а размер файла сжатия должен быть меньше.

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

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

Перемещение папки журнала в удаленную систему

Файлы журнала

IIS по умолчанию хранятся в папке % SystemDrive% \ inetpub \ logs \ LogFiles вашего сервера IIS. Папка настраивается в свойстве Каталог на странице Ведение журнала для сервера или отдельного сайта. Чтобы уменьшить проблему использования диска журналов, вы можете переместить файлы журнала IIS в папку на другом сервере, где есть больше места. Этот сервер может находиться в том же домене, что и локальный сервер IIS, или в другом домене.Вы можете сохранять файлы журналов удаленно либо для всего сервера, либо для отдельных веб-сайтов.

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

Измените расположение файла журнала IIS на удаленный общий ресурс следующим образом:

1. Создайте каталог файлов журнала на удаленном сервере, который находится в том же домене, что и ваш локальный веб-сервер, на котором работает IIS.

2. На странице Properties папки на вкладке Sharing щелкните Share , чтобы открыть общий доступ к каталогу. На вкладке Security назначьте группы и пользователей с соответствующими разрешениями. Убедитесь, что соответствующие группы и пользователи могут читать и записывать файлы журнала.

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

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

3. Откройте IIS Manager на локальном веб-сервере.

4. В IIS Manager на панели Connections щелкните сервер или веб-сайт.

5. Дважды щелкните Регистрация .

6. В текстовом поле Directory введите полный UNC-путь к каталогу, который вы создали на удаленном сервере. Например, введите \ servername \ Logs, где «servername» представляет имя удаленного сервера, а «Logs» представляет имя общего ресурса, где хранятся файлы журналов.

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

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

Удалить старые файлы журнала с помощью сценария

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

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

  sLogFolder = "c: \ inetpub \ logs \ LogFiles"
iMaxAge = 30 минут в днях
Установите objFSO = CreateObject ("Scripting.FileSystemObject")
установить colFolder = objFSO.GetFolder (sLogFolder)
Для каждой colSubfolder в colFolder.Подпапки
        Установите objFolder = objFSO.GetFolder (colSubfolder.Path)
        Установите colFiles = objFolder.Files
        Для каждого objFile в colFiles
                iFileAge = now-objFile.DateCreated
                если iFileAge> (iMaxAge + 1), то
                        objFSO.deletefile objFile, True
                конец, если
        следующий
следующий
  

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

Чтобы запустить сценарий вручную, выполните следующий сценарий в командной строке администратора: cscript.exe c: \ scripts \ retentionscript.vbs

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

Запустить сценарий как запланированную задачу

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

1. Откройте Server Manager , щелкните меню Tools , а затем щелкните Task Scheduler .
2. На панели Действия диалогового окна Планировщик задач щелкните Создать задачу .
3. На вкладке Общие диалогового окна Создать задачу введите имя задачи, например «Удалить файлы журнала».Задайте свойства безопасности, выбрав учетную запись пользователя с достаточными правами для запуска сценария.
4. Щелкните вкладку Triggers , а затем щелкните New . В диалоговом окне Новый триггер установите Начать задачу с на По расписанию . Выберите периодичность, например, Ежедневно . Введите дату Start , выберите дополнительные параметры и убедитесь, что выбрано Enabled , если вы готовы инициировать расписание.Нажмите ОК .
5. Щелкните вкладку Действия , а затем щелкните Новый . В диалоговом окне New Action выберите значение для Action , в данном случае Запустите программу . В программе Program / script введите cscript , а в Добавить аргументы (необязательно) введите путь и имя файла сценария, например C: \ iis \ Log \ _File \ _Deletion.vbs . Нажмите ОК .
6. Щелкните ОК .
7. Убедитесь, что задача была добавлена ​​на панель Активные задачи .
8. Щелкните новую задачу правой кнопкой мыши и выберите Выполнить .
9. Перейдите в папку, в которой выполнялся сценарий, и убедитесь, что соответствующие файлы журнала были удалены.
10. Вернитесь к планировщику задач, щелкните задачу правой кнопкой мыши и выберите Конец , чтобы статус вернулся к Готов и задача готова к запуску по расписанию.

IIS Log Cleaner — это простой инструмент для применения политики хранения журналов для IIS.Инструмент работает в фоновом режиме (один раз в час) и автоматически очищает папку журналов IIS, удаляя файлы журналов старше установленного вами максимального возраста. Файлы журнала перемещаются в корзину, чтобы избежать потенциальной потери данных. Вы также можете запустить процесс очистки вручную или приостановить автоматизированный процесс.

Это сторонний инструмент, не поддерживаемый Microsoft.

Инструмент для чистки файлов

Средство очистки журналов IIS состоит из следующих компонентов:

• IISLogCleaner.exe приложение, которое выполняет процесс очистки журнала. Приложение хранится в локальной папке, которую вы выбираете при загрузке инструмента.

• Файл settings.txt , в котором указывается папка файла журнала, которую нужно очистить, и максимальный возраст, по достижении которого файл журнала удаляется. Параметры по умолчанию — это папка журнала IIS по умолчанию (например, c: \ inetpub \ logs \ LogFiles ) и максимальный срок хранения (в днях) 30. Эти параметры можно настроить, открыв любые параметры.txt в текстовом редакторе или с помощью команды в области уведомлений (см. ниже). Файл settings.txt создается автоматически при первом запуске IISLogCleaner.exe. Файл settings.txt хранится в той же папке, что и IISLogCleaner.exe.

• Значок IIS Log Cleaner в области уведомлений (с надписью IIS). Если щелкнуть правой кнопкой мыши значок уведомления IIS, отобразится список команд действий и параметров состояния:

  • Очистить сейчас выполняет процесс очистки немедленно, а не по времени.
  • Paused останавливает автоматический процесс очистки. Если выбран Paused , вы можете щелкнуть по нему, чтобы перезапустить процесс автоматической очистки.
  • Параметры позволяет настраивать параметры в settings.txt.
  • Exit для выхода из инструмента.

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

Чтобы загрузить, настроить и запустить средство очистки журнала IIS, выполните следующие действия:

1. Загрузите исполняемый файл, выполнив http: // www.erezbenari.com/apps/IISLogCleaner.exe и сохранив исполняемый файл в папке по вашему выбору на сервере (установщика нет).
2. Щелкните всплывающие окна безопасности.
3. Запустите IISLogCleaner.exe в папке. Это создает файл settings.txt в той же папке.
4. Чтобы внести изменения в файл settings.txt, откройте файл в текстовом редакторе или щелкните правой кнопкой мыши значок IIS в области уведомлений, а затем щелкните Параметры .
5. Если вы измените файл настроек, выйдите из инструмента, щелкнув правой кнопкой мыши значок уведомления IIS и выбрав Выход из , а затем снова запустите инструмент.
6. Щелкните правой кнопкой мыши значок IIS в области уведомлений, а затем щелкните Приостановлено , чтобы возобновить работу приложения.
7. Приложение будет запускаться один раз в час и перемещать файлы журналов старше указанного периода в корзину. Чтобы запустить средство очистки вручную, щелкните правой кнопкой мыши значок IIS в области уведомлений, а затем щелкните Очистить сейчас .
8. При желании можно отрегулировать размер корзины, чтобы контролировать, сколько данных журнала хранится перед удалением из корзины операционной системой.

Примечания по использованию:

• Приложение настроено по умолчанию для корневой папки журналов IIS, поэтому оно будет сканировать журналы для всех сайтов (всех подпапок). Если вы хотите, чтобы он очищал только определенный сайт, укажите его в папке сайта.
• Приложение будет перемещать только файлы с расширением .LOG.
• Приложение не является службой, поэтому пользователь должен оставаться в системе, чтобы использовать его.
• Для правильной работы приложению требуется, чтобы вошедший в систему пользователь имел права на запись в папку журнала.
• Если система перезагружается, приложение необходимо перезапустить. Вы можете перетащить его в папку «Автозагрузка», чтобы он запускался при загрузке.

.

Настроить вход в IIS | Документы Microsoft

• 14.04.2013
• 13 минут на чтение

В этой статье

Кейт Ньюман и Роберт Макмеррей

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

Предварительные требования

Чтобы получить максимальную отдачу от этого руководства, у вас должен быть доступ к компьютеру под управлением одной из следующих операционных систем:

• Windows Server® 2012
• Windows® 8

Настроить ведение журнала на уровне сайта

Эту процедуру можно выполнить с помощью пользовательского интерфейса (UI) или путем непосредственного редактирования файлов конфигурации.

Для настройки ведения журнала на уровне сайта с помощью пользовательского интерфейса

1. Откройте диспетчер IIS.

   • Для Windows Server 2012 на странице Start щелкните плитку Server Manager , а затем щелкните OK . В Server Manager щелкните меню Tools , а затем щелкните Internet Information Services (IIS) Manager .
   • Для Windows 8 на странице Пуск введите Панель управления , а затем щелкните значок Панель управления в результатах поиска. На экране панели управления щелкните Система и безопасность , щелкните Администрирование , а затем щелкните Диспетчер информационных служб Интернета (IIS) .

2. В дереве Connections выберите свой веб-сайт.

3. В обзоре функций дважды щелкните Logging .

4. На странице Ведение журнала в разделе файла журнала в разделе Формат выберите один из следующих форматов файла журнала:

   • IIS : использовать формат файла журнала Microsoft IIS для регистрации информации о сайте. Этот формат обрабатывается HTTP.sys и представляет собой фиксированный текстовый формат ASCII, что означает, что вы не можете настраивать поля, которые регистрируются. Поля разделяются запятыми, время записывается как местное. Дополнительные сведения о формате файла журнала IIS см. В разделе Формат файла журнала IIS (IIS 6.0).
   • NCSA : использовать формат файла общего журнала Национального центра суперкомпьютерных приложений (NCSA) для регистрации информации о сайте. Этот формат обрабатывается HTTP.sys и представляет собой фиксированный текстовый формат ASCII, что означает, что вы не можете настраивать поля, которые регистрируются.Поля разделены пробелами, и время записывается как местное время со смещением всемирного координированного времени (UTC). Дополнительные сведения о формате файла журнала NCSA см. В разделе Общий формат файла журнала NCSA (IIS 6.0).
   • W3C : использовать централизованный формат файла журнала W3C для регистрации информации обо всех сайтах на сервере. Этот формат обрабатывается HTTP.sys и представляет собой настраиваемый текстовый формат ASCII, что означает, что вы указываете поля, которые регистрируются. Укажите поля, которые будут регистрироваться в диалоговом окне W3C Logging Fields , нажав Select Fields на странице Logging .Поля разделены пробелами, а время записывается в формате всемирного координированного времени (UTC). Дополнительные сведения о формате файла журнала W3C см. В разделе Расширенный формат файла журнала W3C (IIS 6.0).
   • Custom : для использования настраиваемого формата для настраиваемого модуля регистрации. Когда вы выбираете эту опцию, страница Logging становится недоступной, поскольку настраиваемое ведение журнала не может быть настроено в диспетчере IIS. Дополнительные сведения об использовании пользовательских форматов файлов журнала см. В разделе Пользовательские модули ведения журнала (IIS 6.0).

5. В разделе Directory укажите путь, по которому должен храниться файл журнала. По умолчанию это % SystemDrive% \ inetpub \ logs \ LogFiles .

   Примечание

   Рекомендуется хранить файлы журналов, например журналы трассировки неудачных запросов, в каталоге, отличном от % systemroot% .

6. В разделе Ролловер файла журнала выберите один из следующих вариантов:

   • Расписание : для создания нового файла журнала, основанного на одном из следующих значений:

     • Ежечасно : новый файл журнала создается каждый час.
     • Ежедневно : новый файл журнала создается каждый день.
     • Еженедельно : новый файл журнала создается каждую неделю.
     • Ежемесячно : новый файл журнала создается каждый месяц.

   • Максимальный размер файла (в байтах) : для создания файла журнала, когда файл достигает определенного размера (в байтах). Минимальный размер файла составляет 1048576 байт. Если для этого атрибута установлено значение меньше 1048576 байтов, значение по умолчанию неявно предполагается равным 1048576 байтам.

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

7. Выберите Использовать местное время для именования файлов и одновременного нажатия клавиш , чтобы указать, что для именования файлов журнала и времени смены файлов журнала используется время локального сервера. Если этот параметр не выбран, используется всемирное координированное время (UTC).

   Примечание

   Независимо от этого параметра, метки времени в фактическом файле журнала будут использовать формат времени для формата журнала, который вы выбираете из списка Формат.Например, форматы файлов журнала NCSA и W3C используют формат времени UTC для отметок времени.

8. Щелкните Применить на панели Действия .

Настроить ведение журнала на уровне сервера

Эту процедуру можно выполнить с помощью пользовательского интерфейса (UI) или путем непосредственного редактирования файлов конфигурации.

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

1. В дереве Connections диспетчера IIS выберите свой веб-сервер.

2. В обзоре функций дважды щелкните Logging .

3. На странице Logging в разделе Один файл журнала для каждого сайта , выберите Site из раскрывающегося списка. По умолчанию выбран Сайт .

4. На странице Ведение журнала в разделе файла журнала в разделе Формат выберите один из следующих форматов файла журнала:

   • IIS : использовать формат файла журнала Microsoft IIS для регистрации информации о сайте.Этот формат обрабатывается HTTP.sys и представляет собой фиксированный текстовый формат ASCII, что означает, что вы не можете настраивать поля, которые регистрируются. Поля разделяются запятыми, время записывается как местное. Дополнительные сведения о формате файла журнала IIS см. В разделе Формат файла журнала IIS (IIS 6.0).
   • NCSA : использовать формат файла общего журнала Национального центра суперкомпьютерных приложений (NCSA) для регистрации информации о сайте. Этот формат обрабатывается HTTP.sys и представляет собой фиксированный текстовый формат ASCII, что означает, что вы не можете настраивать поля, которые регистрируются.Поля разделены пробелами, и время записывается как местное время со смещением всемирного координированного времени (UTC). Дополнительные сведения о формате файла журнала NCSA см. В разделе Общий формат файла журнала NCSA (IIS 6.0).
   • W3C : использовать централизованный формат файла журнала W3C для регистрации информации обо всех сайтах на сервере. Этот формат обрабатывается HTTP.sys и представляет собой настраиваемый текстовый формат ASCII, что означает, что вы указываете поля, которые регистрируются. Укажите поля, которые будут регистрироваться в диалоговом окне W3C Logging Fields , нажав Select Fields на странице Logging .Поля разделены пробелами, а время записывается в формате всемирного координированного времени (UTC). Дополнительные сведения о формате файла журнала W3C см. В разделе Расширенный формат файла журнала W3C (IIS 6.0).
   • Custom : для использования настраиваемого формата для настраиваемого модуля регистрации. Когда вы выбираете эту опцию, страница Logging становится недоступной, поскольку настраиваемое ведение журнала не может быть настроено в диспетчере IIS. Дополнительные сведения об использовании пользовательских форматов файлов журнала см. В разделе Пользовательские модули ведения журнала (IIS 6.0).

5. В разделе Directory укажите путь, по которому должен храниться файл журнала. По умолчанию это % SystemDrive% \ inetpub \ logs \ LogFiles .

   Примечание

   Рекомендуется хранить файлы журналов, например журналы трассировки неудачных запросов, в каталоге, отличном от % systemroot% .

6. В разделе Ролловер файла журнала выберите один из следующих вариантов:

   • Расписание : для создания нового файла журнала, основанного на одном из следующих значений:

     • Ежечасно : новый файл журнала создается каждый час.
     • Ежедневно : новый файл журнала создается каждый день.
     • Еженедельно : новый файл журнала создается каждую неделю.
     • Ежемесячно : новый файл журнала создается каждый месяц.

   • Максимальный размер файла (в байтах) : для создания файла журнала, когда файл достигает определенного размера (в байтах). Минимальный размер файла составляет 1048576 байт. Если для этого атрибута установлено значение меньше 1048576 байтов, значение по умолчанию неявно предполагается равным 1048576 байтам.

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

7. Выберите Использовать местное время для именования файлов и одновременного нажатия клавиш , чтобы указать, что для именования файлов журнала и времени смены файлов журнала используется время локального сервера. Если этот параметр не выбран, используется всемирное координированное время (UTC).

   Примечание

   Независимо от этого параметра, метки времени в фактическом файле журнала будут использовать формат времени для формата журнала, который вы выбираете из списка Формат.Например, форматы файлов журнала NCSA и W3C используют формат времени UTC для отметок времени.

8. Щелкните Применить на панели Действия .

Настройка ведения журнала для каждого сервера на уровне сервера

Эту процедуру можно выполнить с помощью пользовательского интерфейса (UI) или путем непосредственного редактирования файлов конфигурации.

Для настройки ведения журнала на уровне сервера с помощью пользовательского интерфейса

1. В дереве Connections диспетчера IIS выберите свой веб-сервер.

2. В обзоре функций дважды щелкните Logging .

3. На странице Ведение журнала в разделе Один файл журнала на сайт выберите Сервер из раскрывающегося списка. По умолчанию выбран Сайт .

4. На странице Ведение журнала в разделе файла журнала в разделе Формат выберите один из следующих форматов файла журнала:

   • IIS : использовать формат файла журнала Microsoft IIS для регистрации информации о сайте.Этот формат обрабатывается HTTP.sys и представляет собой фиксированный текстовый формат ASCII, что означает, что вы не можете настраивать поля, которые регистрируются. Поля разделяются запятыми, время записывается как местное. Дополнительные сведения о формате файла журнала IIS см. В разделе Формат файла журнала IIS (IIS 6.0).
   • NCSA : использовать формат файла общего журнала Национального центра суперкомпьютерных приложений (NCSA) для регистрации информации о сайте. Этот формат обрабатывается HTTP.sys и представляет собой фиксированный текстовый формат ASCII, что означает, что вы не можете настраивать поля, которые регистрируются.Поля разделены пробелами, и время записывается как местное время со смещением всемирного координированного времени (UTC). Дополнительные сведения о формате файла журнала NCSA см. В разделе Общий формат файла журнала NCSA (IIS 6.0).
   • W3C : использовать централизованный формат файла журнала W3C для регистрации информации обо всех сайтах на сервере. Этот формат обрабатывается HTTP.sys и представляет собой настраиваемый текстовый формат ASCII, что означает, что вы указываете поля, которые регистрируются. Укажите поля, которые будут регистрироваться в диалоговом окне W3C Logging Fields , нажав Select Fields на странице Logging .Поля разделены пробелами, а время записывается в формате всемирного координированного времени (UTC). Дополнительные сведения о формате файла журнала W3C см. В разделе Расширенный формат файла журнала W3C (IIS 6.0).
   • Custom : для использования настраиваемого формата для настраиваемого модуля регистрации. Когда вы выбираете эту опцию, страница Logging становится недоступной, поскольку настраиваемое ведение журнала не может быть настроено в диспетчере IIS. Дополнительные сведения об использовании пользовательских форматов файлов журнала см. В разделе Пользовательские модули ведения журнала (IIS 6.0).

5. В разделе Directory укажите путь, по которому должен храниться файл журнала. По умолчанию это % SystemDrive% \ inetpub \ logs \ LogFiles .

   Примечание

   Рекомендуется хранить файлы журналов, например журналы трассировки неудачных запросов, в каталоге, отличном от % systemroot% .

6. В разделе Ролловер файла журнала выберите один из следующих вариантов:

   • Расписание : для создания нового файла журнала, основанного на одном из следующих значений:

     • Ежечасно : новый файл журнала создается каждый час.
     • Ежедневно : новый файл журнала создается каждый день.
     • Еженедельно : новый файл журнала создается каждую неделю.
     • Ежемесячно : новый файл журнала создается каждый месяц.

   • Максимальный размер файла (в байтах) : для создания файла журнала, когда файл достигает определенного размера (в байтах). Минимальный размер файла составляет 1048576 байт. Если для этого атрибута установлено значение меньше 1048576 байтов, значение по умолчанию неявно предполагается равным 1048576 байтам.

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

7. Выберите Использовать местное время для именования файлов и одновременного нажатия клавиш , чтобы указать, что для именования файлов журнала и времени смены файлов журнала используется время локального сервера. Если этот параметр не выбран, используется всемирное координированное время (UTC).

   Примечание

   Независимо от этого параметра, метки времени в фактическом файле журнала будут использовать формат времени для формата журнала, который вы выбираете из списка Формат.Например, форматы файлов журнала NCSA и W3C используют формат времени UTC для отметок времени.

8. Щелкните Применить на панели Действия .

Выберите поля W3C для регистрации

Эту процедуру можно выполнить с помощью пользовательского интерфейса (UI) или путем непосредственного редактирования файлов конфигурации.

Чтобы выбрать поля W3C для регистрации с помощью пользовательского интерфейса

1. В обзоре функций диспетчера IIS дважды щелкните Logging .

2. На странице Ведение журнала в разделе файла журнала в разделе Формат щелкните Выбрать поля .

3. В диалоговом окне W3C Logging Fields выберите один или несколько из следующих параметров:

   • Дата (дата) : дата возникновения запроса.
   • Время (время) : время в формате всемирного координированного времени (UTC), когда возник запрос.
   • IP-адрес клиента (c-ip) : IP-адрес клиента, сделавшего запрос.
   • Имя пользователя (cs-username) : имя аутентифицированного пользователя, который получил доступ к вашему серверу. Анонимные пользователи обозначаются дефисом.
   • Имя службы (s-sitename) : номер экземпляра сайта, который выполнил запрос.
   • Имя сервера (s-computername) : имя сервера, на котором была создана запись файла журнала.
   • IP-адрес сервера (s-ip) : IP-адрес сервера, на котором была создана запись файла журнала.
   • Порт сервера (s-порт) : номер порта сервера, настроенный для службы.
   • Метод (cs-method) : запрошенное действие, например, метод GET.
   • URI Stem (cs-uri-stem) : универсальный идентификатор ресурса или цель действия.
   • URI Query (cs-uri-query) : запрос, если таковой имеется, который пытался выполнить клиент. Запрос универсального идентификатора ресурса (URI) необходим только для динамических страниц.
   • Состояние протокола (sc-status) : код состояния HTTP или FTP.
   • Подстатус протокола (sc-substatus) : код подстатуса HTTP или FTP.
   • Состояние Win32 (sc-win32-status) : код состояния Windows.
   • отправленных байт (sc-байты) : количество байтов, отправленных сервером.
   • полученных байтов (cs-bytes) : количество байтов, полученных сервером.
   • Time Taken (затраченное время) : продолжительность действия в миллисекундах.
   • Версия протокола (cs-version) : версия протокола, которую использовал клиент.
   • Хост (cs-host) : имя хоста, если есть.
   • Пользовательский агент (cs (UserAgent)) : тип браузера, который использовал клиент.
   • Cookie (cs (Cookie)) : содержимое отправленного или полученного файла cookie, если таковое имеется.
   • Реферер (cs (реферер)) : сайт, который пользователь последний раз посещал. Этот сайт предоставил ссылку на текущий сайт.

4. Щелкните Применить на панели Действия .

Настройка параметров ролловера файла журнала

Эту процедуру можно выполнить с помощью пользовательского интерфейса (UI) или путем непосредственного редактирования файлов конфигурации.

Для настройки параметров одновременного нажатия клавиш файла журнала с помощью пользовательского интерфейса

1. В обзоре функций диспетчера IIS дважды щелкните Logging .

2. На странице Logging , в разделе Log File Rollover выберите один из следующих вариантов:

   • Расписание : для создания нового файла журнала, основанного на одном из следующих значений:

     • Ежечасно : новый файл журнала создается каждый час.
     • Ежедневно : новый файл журнала создается каждый день.
     • Еженедельно : новый файл журнала создается каждую неделю.
     • Ежемесячно : новый файл журнала создается каждый месяц.

   • Максимальный размер файла (в байтах) : для создания файла журнала, когда файл достигает определенного размера (в байтах). Минимальный размер файла составляет 1048576 байт. Если для этого атрибута установлено значение меньше 1048576 байтов, значение по умолчанию неявно предполагается равным 1048576 байтам.

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

3. Выберите Использовать местное время для именования файлов и одновременного нажатия клавиш , чтобы указать, что для именования файлов журнала и времени смены файлов журнала используется время локального сервера.Если этот параметр не выбран, используется всемирное координированное время (UTC).

   Примечание

   Независимо от этого параметра, метки времени в фактическом файле журнала будут использовать формат времени для формата журнала, который вы выбираете из списка Формат. Например, форматы файлов журнала NCSA и W3C используют формат времени UTC для отметок времени.

4. Щелкните Применить на панели Действия .

См. Также

.

Куда идут журналы при запуске ASP.NET Core на IIS 7.5?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

.

Ведение журнала IIS — приложения Win32

• 31.05.2018
• 2 минуты на чтение

В этой статье

Ведение журнала IIS — это один из типов ведения журнала на стороне сервера, который можно включить для группы URL-адресов. Формат файла журнала IIS — это фиксированный текстовый формат ASCII, который нельзя настроить.Файл журнала IIS содержит попадания в кэш режима ядра API HTTP-сервера. Этот тип ведения журнала можно включить только для группы URL-адресов; его нельзя использовать в сеансе сервера.

Формат файла журнала IIS записывает следующие данные. Данные в таблице указаны в порядке появления в файле журнала.

Не все поля будут содержать информацию.Для полей, для которых нет информации, вместо заполнителя отображается дефис (-). Если поле содержит непечатаемый символ, API HTTP-сервера заменяет его знаком плюс (+), чтобы сохранить формат файла журнала. Обычно это происходит при вирусных атаках, когда, например, злоумышленник отправляет символы возврата каретки и перевода строки, которые, если их не заменить знаком плюс (+), нарушат формат файла журнала. Поля разделяются запятыми, что упрощает чтение формата по сравнению с другими форматами ASCII, в которых в качестве разделителей используются пробелы.Время записывается как местное. Затраченное время записывается в миллисекундах. Для получения дополнительной информации о поле затраченного времени см. Раздел «Ведение журнала W3C».

В следующем примере показана запись в файле журнала NCSA Common.

  192.168.114.201, -, 20.03.05, 7:55:20, W3SVC2, СЕРВЕР,
172.21.13.45, 4502, 163, 3223, 200, 0, GET, /DeptLogo.gif, -,
  

.