Вопрос или проблема
На Windows Server, который я рассматриваю, IIS запускает службу публикации WWW, и для этой службы настроен брандмауэр, разрешающий только порты 80 и 443. Подключения из браузеров клиентов приводят к тайм-ауту, и когда я смотрю журнал событий безопасности на сервере, я вижу такие события:
Платформа фильтрации Windows заблокировала подключение.
Информация о приложении:
Идентификатор процесса: 4
Имя приложения: System
Информация о сети:
Направление: Входящее
Адрес источника: 192.168.10.21 <= Это сервер, где зарегистрировано событие
Порт источника: 80 <= Это порт прослушивания службы публикации IIS WWW
Адрес назначения: 192.168.10.3 <= Это клиентский ПК, где браузер запрашивает URL на IIS
Порт назначения: 60112
Протокол: 6
Информация о фильтре:
Идентификатор фильтра во время выполнения: 86327
Имя уровня: Принять/Получить
Идентификатор уровня во время выполнения: 44
Если подключение действительно входящее, как сказано выше, то источником должен быть 192.168.10.3, порт источника должен быть случайным высоким портом, который использует браузер, адрес назначения должен быть 192.168.10.21, а порт назначения — 80, но все наоборот.
Не понимая, почему поля события перепутаны, я не могу придумать, как разрешить это подключение.
Если это действительно не оригинальный запрос, а ответ от IIS на запрос, который был разрешен, то почему он блокируется? На брандмауэре нет правил блокировки, и единственное правило, касающееся соединений HTTP(s), — это правило разрешения входящих соединений для службы IIS WWW.
Я настроил множество серверов Apache и связанных с ними правил, как описано выше, и никогда не сталкивался с какими-либо проблемами. Если IIS требует другого подхода, то зачем и как? Это требование поставщика, чтобы сайт работал на IIS, так что в этом отношении у меня нет свободы действий.
Ответ или решение
Ваш вопрос о некорректной трактовке направлений и адресов в событиях безопасности Windows Server действительно требует внимания, так как он имеет значение для диагностики и разрешения проблемы с блокировкой соединений в IIS. Чтобы разобраться в этом, разберем проблему на нескольких уровнях.
Теория
Первое, что необходимо понять, это то, как работает Windows Filtering Platform (WFP) и как она взаимодействует с правилами межсетевого экрана. WFP — это компонент, который предоставляет API для фильтрации сетевых пакетов и мониторинга сетевой активности. Межсетевой экран сервера основан на политиках, сформированных с учётом этих элементов.
Когда IIS отвечает на HTTP-запросы, он не только принимает входящие соединения, но также может инициировать исходящие к клиентским ПК в рамках уже установленных сеансов связи. Обычно это отражается в безопасности на уровне межсетевого экрана.
Пример
Разберём конкретный пример из вашего описания. Лог сообщений, указанное вами, обозначает, что Windows Filtering Platform блокирует соединение с процессом, ID которого соответствует ядру системы (обычно это PID 4). Здесь стоит обратить внимание на то, что данные события могут регистрировать не только попытки входящих соединений, но и действия ответа.
Применение
Теперь применяется следующая стратегия для решения проблемы:
-
Анализ политики межсетевого экрана: необходимо проверить правила межсетевого экрана на предмет возможных недопониманий в правилах. Хотя правило для порта 80 кажется правильным, важнее понять, что в блокировке более широкая проблема. Проверьте, нет ли слишком строгих правил для обратных ответов из IIS к клиентам.
-
Использование логов IIS: включите и изучите расширенные логи IIS для установления всех аспектов подключения. Это может дать более полное представление о том, как IIS обрабатывал запросы и ответы.
-
Применение правил Accept и Receive/Accept: расширьте правило приёма, направленного специально на обнаруженные при анализе источники и назначения, чтобы убедиться, что соответствующее правило включает все нужные порты и протоколы на уровне ответов.
-
Диагностика межсетевого экрана: используйте команды netsh или политики групповой политики, чтобы детально проверять и изменять настройки WFP в режиме реального времени. Это может помочь более точно откалибровать правила.
Такой методический подход позволит вашему серверу IIS обрабатывать входящие и исходящие соединения без блокировок, обеспечивая стабильную работу веб-сервиса.