Я использую Windows 2008 R2, и у меня есть IIS7 / MySQL, на которых размещено несколько веб-сайтов. Однако в последнее время у меня возникали, казалось бы, случайные ошибки подключения, возможно, один раз из 50.
Я взглянул на средство просмотра событий и обнаружил, что существует множество заблокированных пакетов для публикации 80 с разных IP-адресов на момент возникновения проблем, включая мой собственный (журнал средства просмотра событий прикреплен внизу сообщения).
Похоже, что WFP блокирует некоторые законные запросы, но я настроил брандмауэр, чтобы разрешить все подключения веб-трафика через порт 80 ... так как же их заблокировать?
ЖУРНАЛ:
The Windows Filtering Platform has blocked a packet.
Application Information:
Process ID: 0
Application Name: -
Network Information:
Direction: Inbound
Source Address: xxx.xxx.xxx.xxx
Source Port: 57578
Destination Address: xxx.xxx.xxx.xxx
Destination Port: 80
Protocol: 6
Filter Information:
Filter Run-Time ID: 74587
Layer Name: Transport
Layer Run-Time ID: 13
Если вы действительно хотите разобраться в этой проблеме, вам нужно будет выполнить захват WFP (Windows Filtering Platform).
Чтобы начать захват, используйте следующую команду:
netsh wfp capture start
Затем вы должны воспроизвести вашу проблему, чтобы включить ее в захват. После этого вы используете следующую команду, чтобы остановить захват:
netsh wfp capture stop
Результат захвата сохраняется в файле wfpdiag.cab в текущем каталоге. Я считаю, что этот файл предназначен только для внутреннего использования Microsoft, но при желании вы можете извлечь два файла из архива и посмотреть сами.
В .etl можно открыть с помощью журнала событий. Однако я не уверен, как интерпретировать содержание. Интересный файл .xml файл. Если вы потратите какое-то время, вы сможете понять структуру содержимого. Вам следует искать следующее:
Идентификатор среды выполнения фильтра: 74587
Изучив XML, вы должны определить, какой фильтр имеет идентификатор среды выполнения 74587. Это скажет вам, какое правило в брандмауэре заблокировало соединение. Обратите внимание, что в брандмауэре есть некоторые скрытые правила (например, правила усиления службы брандмауэра Windows).
Как уже упоминалось Вот, вполне вероятно, что эти записи журнала событий (с идентификатором события 5152) вызваны вредоносными запросами, возможно, отправленными законными пользователями вашего веб-сайта, которые имеют зараженные вирусом машины. Вирусы, такие как Код красный распространяется таким образом, заражая веб-сайты, работающие на IIS. IIS / WFP, скорее всего, блокирует и регистрирует вредоносные запросы.
Если предположить, что это так, здесь особо нечего делать. Если вы определите, что все запросы поступают с одного IP-адреса, вы можете заблокировать этот IP-адрес на уровне брандмауэра. Если они поступают отовсюду, и вы больше не хотите, чтобы вас беспокоили записи журнала событий, вы можете отключить ведение журнала аудита этих событий (не то чтобы я обязательно рекомендовал это делать). Если вы действительно хотите отключить ведение журнала, вы можете использовать auditpol.exe команда.
Просмотрите настройки журнала аудита для событий 5152 и 5153:
auditpol /get /subcategory:"Filtering Platform Packet Drop"
Отключите журнал аудита отказов для событий 5152 и 5153:
auditpol /set /subcategory:"Filtering Platform Packet Drop" /failure:disable
Более подробную информацию о Политике аудита можно найти по адресу:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb309058(v=vs.85).aspx