Журналы для Брандмауэра веб-приложений 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. Журналы 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 найдите нужный ресурс и выберите Diagnostic settings (Настройки диагностики).
Для шлюза приложений доступны три журнала:
- журнал доступа;
- журнал производительности;
- журнал брандмауэра.
Выберите Добавить параметр диагностики.
На странице Параметры диагностики представлены параметры для журналов ресурсов. В этом примере для хранения журналов используется Log Analytics. Для сохранения журналов ресурсов можно также использовать концентратор событий, учетную запись хранения или партнерское решение.
Введите имя для настроек, подтвердите их и нажмите Save (Сохранить).
Журнал действий
На портале 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. |
| узел | Имя узла, с которого запрос был отправлен на внутренний сервер. При переопределении серверного имени узла это имя будет отражать это. |
| 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": "191.96.249.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=874f1f0f-6807-41c9-b7bc-f3cfa74aa0b1&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-код состояния HTTP внутреннего сервера. |
| serverResponseLatency | Задержка ответа от внутреннего сервера. |
| узел | Адрес, указанный в заголовке узла запроса. |
{
"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": "191.96.249.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 | Число обрабатываемых запросов. |
| Задержка | Средняя задержка (в миллисекундах) запросов от экземпляра к серверной части, обрабатывающей запросы. |
| 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-адрес источника запроса. |
| clientPort | Порт источника запроса. |
| requestUri | URL-адрес полученного запроса. |
| ruleSetType | Тип набора правил. Доступное значение — OWASP. |
| ruleSetVersion | Используемая версия набора правил. Возможные значения: 2.2.9 и 3.0. |
| ruleId | Идентификатор правила события-триггера. |
| message | Понятное сообщение для события-триггера. Дополнительные сведения приведены в разделе details. |
| action | Режим политики: Обнаружение - обнаружено — это единственное действие для WAF в режиме обнаружения. Все условия для данного правила были сопоставлены, и запрос был записан в журнал, а затем передан в серверную часть. Режим политики: Предотвращение - разрешено . Все условия были сопоставлены для данного правила, и запрос был передан в серверную часть. - Заблокировано — все условия были сопоставлены для заданного правила, а запрос заблокирован. - Сопоставлено — одно или несколько условий были сопоставлены для данного правила, но решение о блокировке или передаче запроса потребует дальнейшей оценки и будет оцениваться на основе окончательного правила оценки аномалий. |
| site | Сайт, для которого создан журнал. В нашем случае возможно только значение Global, так как применяются глобальные правила. |
| подробности | Сведения о событии-триггере. |
| 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": "52.161.109.147",
"clientPort": "0",
"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/1496a758-b2ff-43ef-b738-8e9eb5161a86/resourceGroups/drewRG/providers/Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/perListener",
"policyScope": "Listener",
"policyScopeName": "httpListener1"
}
}
}
Просмотр и анализ журнала действий
Данные журнала действий можно просматривать и анализировать с помощью любого из следующих методов:
- Средства Azure. Информацию из журналов действий можно получать с помощью Azure PowerShell, Azure CLI, REST API Azure или портала 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 и других средств).