Журналы для Брандмауэра веб-приложений Azure
Вы можете отслеживать ресурсы Брандмауэра веб-приложений с помощью журналов. Вы можете сохранить производительность, доступ и другие данные или использовать их из ресурса для мониторинга.
Примечание.
Мы рекомендуем использовать модуль Azure Az PowerShell для взаимодействия с Azure. Чтобы начать работу, см. статью Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.
Журналы диагностики
В Azure можно использовать различные виды журналов для управления шлюзами приложений и устранения возникающих в них неполадок. Доступ к некоторым из этих журналов можно получить через портал. Также можно извлечь все журналы из хранилища BLOB-объектов Azure и просматривать их с помощью таких средств, как журналы Azure Monitor, Excel и Power BI. В списке ниже приведены дополнительные сведения о разных типах журналов:
- Журнал действий. В журналах действий Azure можно просматривать все операции, отправляемые в вашу подписку Azure, и состояние этих операций. Записи этого журнала собираются по умолчанию, и их можно просмотреть на портале Azure.
- Журнал доступа к ресурсам. Этот журнал можно использовать для просмотра схем доступа к Шлюзу приложений и анализа важных сведений. Сюда входят IP-адрес вызывающего абонента, запрошенный URL-адрес, задержка ответа, код возврата и входящие и исходящие байты. Этот журнал содержит отдельные записи для каждого запроса и связывает запрос с уникальным Шлюзом приложений, обрабатывающим запрос. Уникальные экземпляры Шлюза приложений можно идентифицировать по свойству instanceId.
- Журнал производительности ресурса. С помощью этого журнала можно просматривать, как работают экземпляры Шлюза приложений. В этот журнал записываются сведения о производительности каждого экземпляра, включая общее число обработанных запросов, пропускную способность в байтах, число неудачных запросов, а также число работоспособных и неработоспособных серверных экземпляров. Данные для журнала производительности собираются каждые 60 секунд. Журнал производительности доступен только для номера SKU версии 1. Для номера SKU версии 2 используйте метрики для данных производительности.
- Журнал производительности брандмауэра. Этот журнал можно использовать для просмотра запросов, которые были зарегистрированы в режиме обнаружения или предотвращения в шлюзе приложений, в котором настроен брандмауэр веб-приложения.
Примечание.
Журналы доступны только для ресурсов, развернутых в модели развертывания с помощью Azure Resource Manager. Журналы нельзя использовать для ресурсов в классической модели развертывания. Чтобы получить более полное представление об этих двух моделях, см. статью Развертывание с помощью Azure Resource Manager и классическое развертывание: сведения о моделях развертывания и состоянии ресурсов.
Существует три способа хранения журналов:
- Учетная запись хранения лучше всего подходит для длительного хранения журналов и их просмотра по мере необходимости.
- Центры событий — это отличный вариант для интеграции с другими инструментами управления событиями и сведениями о безопасности (SIEM), позволяющий получать оповещения о ваших ресурсах.
- Журналы Azure Monitor: лучше всего подходят для общего мониторинга вашего приложения в реальном времени и изучения тенденций.
Включение ведения журнала с помощью PowerShell
Ведение журнала действий автоматически включается для каждого ресурса Resource Manager. Нужно включить ведение журналов доступа и производительности, чтобы начать сбор связанных данных. Вот как можно включить ведение журнала:
Запишите или запомните ИД ресурса учетной записи хранения, где хранятся данные журнала, в формате: /subscriptions/<идентификатор_подписки>/resourceGroups/<имя_группы_ресурсов>/providers/Microsoft.Storage/storageAccounts/<имя_учетной_записи_хранения>. Можно использовать любую учетную запись хранения в подписке. Получить эти сведения можно на портале Azure.
Запишите или запомните идентификатор ресурса шлюза приложений, для которого нужно включить ведение журнала. в формате: /subscriptions/<идентификатор_подписки>/resourceGroups/<имя_группы_ресурсов>/providers/Microsoft.Network/applicationGateways/<имя_шлюза_приложений>. Получить эти сведения можно на портале.
Включите ведение журнала ресурса с помощью следующего командлета PowerShell:
Set-AzDiagnosticSetting -ResourceId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name> -StorageAccountId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name> -Enabled $true
Совет
Журналы действий не требуют отдельной учетной записи хранения. За использование хранилища для журналов доступа и производительности взимается плата.
Включение ведения журнала на портале Azure
На портале Azure найдите нужный ресурс и выберите Параметры диагностики.
Для шлюза приложений доступны три журнала:
- журнал доступа;
- журнал производительности;
- журнал брандмауэра.
Выберите Добавить параметр диагностики.
Страница параметров диагностики предоставляет параметры для журналов ресурсов. В этом примере для хранения журналов используется Log Analytics. Вы также можете использовать концентратор событий, учетную запись хранения или партнерское решение для сохранения журналов ресурсов.
Введите имя для параметров, подтвердите их и нажмите Сохранить.
Журнал действий
На портале Azure журнал действий создается по умолчанию. Журналы хранятся в течение 90 дней в хранилище журналов событий Azure. Дополнительные сведения об этих журналах см. в статье Просмотр журналов действий для аудита действий с ресурсами.
журнал доступа;
Журнал доступа создается, только если он включен для каждого экземпляра шлюза приложений, как описано выше. Данные хранятся в учетной записи хранения, указанной при включении ведения журнала. Каждая операция доступа Шлюза приложений регистрируется в журнале в формате JSON, как показано в примере ниже для версии 1.
значение | Описание |
---|---|
instanceId | Экземпляр шлюза приложений, который обрабатывает запрос. |
clientIP | IP-адрес источника запроса. |
clientPort | Порт источника запроса. |
httpMethod | Метод HTTP, используемый для запроса. |
requestUri | URI полученного запроса. |
RequestQuery | Направлен сервером: экземпляр серверного пула, который отправил запрос. X-AzureApplicationGateway-log-ID: идентификатор корреляции, используемый для запроса. Он может использоваться для устранения неполадок с трафиком на внутренних серверах. SERVER-STATUS — код отклика HTTP, полученный шлюзом приложений из серверной части. |
UserAgent | Агент пользователя из заголовка HTTP-запроса. |
httpStatus | Код состояния HTTP, возвращаемый клиенту из шлюза приложений. |
httpVersion | Версия HTTP для запроса. |
receivedBytes | Размер полученного пакета (в байтах). |
sentBytes | Размер отправленного пакета (в байтах). |
timeTaken | Время (в миллисекундах), необходимое для обработки запроса и отправки ответа. Вычисляется как промежуток времени от момента, когда шлюз приложений получает первый байт HTTP-запроса, до завершения отправки ответа. Важно отметить, что в поле Time-Taken обычно указывается время передачи пакетов запросов и ответов по сети. |
sslEnabled | Определяет, используется ли TLS/SSL для обмена данными с внутренними пулами. Допустимые значения: on и off. |
host | Имя узла, с которого запрос был отправлен на внутренний сервер. При переопределении серверного имени узла это имя будет отражать это. |
originalHost | Имя узла, с которым шлюз приложений получил запрос от клиента. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/PEERINGTEST/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayAccess",
"timestamp": "2017-04-26T19:27:38Z",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIP": "203.0.113.97",
"clientPort": 46886,
"httpMethod": "GET",
"requestUri": "/phpmyadmin/scripts/setup.php",
"requestQuery": "X-AzureApplicationGateway-CACHE-HIT=0&SERVER-ROUTED=10.4.0.4&X-AzureApplicationGateway-LOG-ID=aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e&SERVER-STATUS=404",
"userAgent": "-",
"httpStatus": 404,
"httpVersion": "HTTP/1.0",
"receivedBytes": 65,
"sentBytes": 553,
"timeTaken": 205,
"sslEnabled": "off",
"host": "www.contoso.com",
"originalHost": "www.contoso.com"
}
}
Для Шлюза приложений и WAF версии 2 журналы содержат несколько дополнительных сведений:
значение | Описание |
---|---|
instanceId | Экземпляр шлюза приложений, который обрабатывает запрос. |
clientIP | IP-адрес источника запроса. |
clientPort | Порт источника запроса. |
httpMethod | Метод HTTP, используемый для запроса. |
requestUri | URI полученного запроса. |
UserAgent | Агент пользователя из заголовка HTTP-запроса. |
httpStatus | Код состояния HTTP, возвращаемый клиенту из шлюза приложений. |
httpVersion | Версия HTTP для запроса. |
receivedBytes | Размер полученного пакета (в байтах). |
sentBytes | Размер отправленного пакета (в байтах). |
timeTaken | Время (в миллисекундах), необходимое для обработки запроса и отправки ответа. Вычисляется как промежуток времени от момента, когда шлюз приложений получает первый байт HTTP-запроса, до завершения отправки ответа. Важно отметить, что в поле Time-Taken обычно указывается время передачи пакетов запросов и ответов по сети. |
sslEnabled | Определяет, используется ли TLS для обмена данными с внутренними пулами. Допустимые значения: on и off. |
sslCipher | Набор шифров, используемый для обмена данными TLS (если включен протокол TLS). |
sslProtocol | Используемый протокол TLS (если TLS включен). |
serverRouted | Внутренний сервер, на который шлюз приложений направляет запрос. |
serverStatus | Код состояния HTTP внутреннего сервера. |
serverResponseLatency | Задержка ответа от внутреннего сервера. |
host | Адрес, указанный в заголовке узла запроса. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/PEERINGTEST/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayAccess",
"time": "2017-04-26T19:27:38Z",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "appgw_1",
"clientIP": "203.0.113.97",
"clientPort": 46886,
"httpMethod": "GET",
"requestUri": "/phpmyadmin/scripts/setup.php",
"userAgent": "-",
"httpStatus": 404,
"httpVersion": "HTTP/1.0",
"receivedBytes": 65,
"sentBytes": 553,
"timeTaken": 205,
"sslEnabled": "off",
"sslCipher": "",
"sslProtocol": "",
"serverRouted": "104.41.114.59:80",
"serverStatus": "200",
"serverResponseLatency": "0.023",
"host": "www.contoso.com",
}
}
журнал производительности;
Журнал производительности создается, только если он включен для каждого экземпляра шлюза приложений, как описано выше. Данные хранятся в учетной записи хранения, указанной при включении ведения журнала. Данные журнала производительности формируются с интервалом в 1 минуту. Они доступны только для номера SKU версии 1. Для номера SKU версии 2 используйте метрики для данных производительности. В журнал записываются следующие данные:
значение | Описание |
---|---|
instanceId | Экземпляр шлюза приложений, для которого формируются данные о производительности. Если экземпляров шлюза приложений несколько, каждому экземпляру будет соответствовать определенная строка. |
healthyHostCount | Число работоспособных узлов во внутреннем пуле. |
unHealthyHostCount | Число неработоспособных узлов во внутреннем пуле. |
requestCount | Число обрабатываемых запросов. |
latency | Средняя задержка (в миллисекундах) запросов от экземпляра к серверной части, обрабатывающей запросы. |
failedRequestCount | Количество невыполненных запросов. |
throughput | Средняя пропускная способность (в байтах в секунду) с момента создания последнего журнала. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayPerformance",
"time": "2016-04-09T00:00:00Z",
"category": "ApplicationGatewayPerformanceLog",
"properties":
{
"instanceId":"ApplicationGatewayRole_IN_1",
"healthyHostCount":"4",
"unHealthyHostCount":"0",
"requestCount":"185",
"latency":"0",
"failedRequestCount":"0",
"throughput":"119427"
}
}
Примечание.
Задержка вычисляется от момента получения первого байта HTTP-запроса до момента отправки последнего байта HTTP-отклика. Это сумма времени обработки шлюза приложений, времени передачи по сети к серверной части, а также времени, необходимого для обработки запроса в серверной части.
журнал брандмауэра.
Этот журнал создается, только если он включен для каждого шлюза приложений, как описано выше. Кроме того, в шлюзе приложений должен быть настроен брандмауэр веб-приложения. Данные хранятся в назначении, указанном при включении ведения журнала. В журнал записываются следующие данные:
значение | Описание |
---|---|
instanceId | Экземпляр шлюза приложений, для которого формируются данные о брандмауэре. Если экземпляров шлюза приложений несколько, каждому экземпляру будет соответствовать определенная строка. |
clientIp | IP-адрес источника запроса. |
requestUri | URL-адрес полученного запроса. |
ruleSetType | Тип набора правил. Доступное значение — OWASP. |
ruleSetVersion | Используемая версия набора правил. Возможные значения: 2.2.9 и 3.0. |
ruleId | Идентификатор правила события-триггера. |
message | Понятное сообщение для события-триггера. Дополнительные сведения приведены в разделе details. |
действие | Режим политики: обнаружено обнаружение - . Это единственное действие для WAF в режиме обнаружения. Все условия для заданного правила были сопоставлены, и запрос был зарегистрирован, а затем передан в серверную часть. Режим политики: разрешено предотвращение - . Все условия соответствовали заданному правилу, и запрос был передан в серверную часть. - Заблокировано . Все условия были сопоставлены для данного правила, и запрос был заблокирован. - Соответствует одному или нескольким условиям, которые соответствуют заданному правилу, но решение заблокировать или передать запрос потребует дальнейшего вычисления и будет оцениваться на основе окончательного правила оценки аномалий. Режим политики: вызов JS - JSChallengeIssued: выдан из-за отсутствия или недопустимого разрешения на вызов, отсутствующий ответ. Этот журнал создается, когда клиент запрашивает доступ к веб-приложению впервые и ранее не был оспорен. Этот клиент получает страницу задач JS и переходит к вычислению задачи JS. При успешном вычислении клиент получает файл cookie допустимости. - JSChallengePass: передан из-за допустимого ответа на вызов. Этот журнал создается, когда клиент решает задачу JS и повторно отправляет запрос с правильным ответом. В этом случае Azure WAF проверяет файл cookie и переходит к обработке оставшихся правил без создания другого вызова JS. - JSChallengeValid: Loged/passthrough из-за допустимой проблемы Этот журнал создается, когда клиент ранее решил проблему. В этом случае Azure WAF регистрирует запрос и переходит к обработке оставшихся правил. - JSChallengeBlock: заблокирован Этот журнал создается при сбое вычисления проблем JS. |
site | Сайт, для которого создан журнал. В нашем случае возможно только значение Global, так как применяются глобальные правила. |
details | Сведения о событии-триггере. |
details.message | Описание правила. |
details.data | Определенные данные из запроса, которые соответствуют правилу. |
details.file | Файл конфигурации, содержащий правило. |
details.line | Номер строки в файле конфигурации, активировавшей событие. |
hostname | Имя узла или IP-адрес Шлюза приложений. |
transactionId | Уникальный идентификатор для данной транзакции, который помогает сгруппировать несколько нарушений правил, произошедших в одном запросе. |
policyId | Уникальный идентификатор политики брандмауэра, связанной с Шлюзом приложений, прослушивателем или путем. |
policyScope | В качестве расположения политики можно указать одно из значений "Global", "Listener" или "Location". |
policyScopeName | Имя объекта, к которому применяется политика. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"time": "2017-03-20T15:52:09.1494499Z",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIp": "203.0.113.147",
"requestUri": "/",
"ruleSetType": "OWASP",
"ruleSetVersion": "3.0",
"ruleId": "920350",
"ruleGroup": "920-PROTOCOL-ENFORCEMENT",
"message": "Host header is a numeric IP address",
"action": "Matched",
"site": "Global",
"details": {
"message": "Warning. Pattern match \"^[\\\\d.:]+$\" at REQUEST_HEADERS:Host ....",
"data": "127.0.0.1",
"file": "rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
"line": "791"
},
"hostname": "127.0.0.1",
"transactionId": "16861477007022634343",
"policyId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/drewRG/providers/Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/perListener",
"policyScope": "Listener",
"policyScopeName": "httpListener1"
}
}
}
Просмотр и анализ журнала действий
Данные журнала действий можно просматривать и анализировать с помощью любого из следующих методов:
- Средства Azure. Информацию из журналов действий можно получать с помощью Azure PowerShell, Azure CLI, Azure REST API или портала Azure. Пошаговые инструкции для каждого метода подробно описаны в статье Activity operations with Resource Manager (Выполнение операций в журналах действий с помощью Resource Manager).
- Power BI. Если у вас еще нет учетной записи Power BI, вы можете использовать бесплатную пробную версию. С помощью приложение-шаблонов Power BI можно анализировать данные.
Просмотр и анализ журналов доступа, производительности и брандмауэра
Журналы Azure Monitor позволяют собирать файлы журналов счетчиков и событий из вашей учетной записи хранилища BLOB-объектов. Эта служба предоставляет средства визуализации и эффективные возможности поиска для анализа журналов.
Вы также можете подключиться к учетной записи хранения и извлечь записи журнала JSON для журналов доступа и производительности. После скачивания JSON-файлов их можно преобразовать в формат CSV и просматривать в Excel, Power BI или другом средстве визуализации данных.
Совет
Если вы знакомы с Visual Studio и основными понятиями изменения значений констант и переменных в C#, можно использовать инструменты преобразования журналов, доступные на сайте GitHub.
Анализ журналов доступа через GoAccess
Мы опубликовали шаблон Resource Manager, который устанавливает и запускает популярный анализатор журналов GoAccess для журналов доступа шлюза приложений. GoAccess предоставляет ценную статистику трафика HTTP, такую как уникальные посетители, запрошенные файлы, узлы, операционные системы, браузеры, коды состояния HTTP и многое другое. Дополнительные сведения см. в файле сведений в папке шаблона Resource Manager на GitHub.
Следующие шаги
- См. сведения о визуализации журналов счетчиков и событий с помощью журналов Azure Monitor.
- Прочтите запись блога Visualize your Azure Activity Log with Power BI (Визуализация журналов действий Azure с помощью Power BI).
- Прочтите запись блога View and analyze Azure Audit Logs in Power BI and more (Просмотр и анализ журналов аудита Azure с помощью Power BI и других средств).