Эта ошибка сервера ставит меня в тупик: сочетание направления соединения, источника и назначения не имеет смысла.

Вопрос или проблема

На 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). Здесь стоит обратить внимание на то, что данные события могут регистрировать не только попытки входящих соединений, но и действия ответа.

Применение

Теперь применяется следующая стратегия для решения проблемы:

  1. Анализ политики межсетевого экрана: необходимо проверить правила межсетевого экрана на предмет возможных недопониманий в правилах. Хотя правило для порта 80 кажется правильным, важнее понять, что в блокировке более широкая проблема. Проверьте, нет ли слишком строгих правил для обратных ответов из IIS к клиентам.

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

  3. Применение правил Accept и Receive/Accept: расширьте правило приёма, направленного специально на обнаруженные при анализе источники и назначения, чтобы убедиться, что соответствующее правило включает все нужные порты и протоколы на уровне ответов.

  4. Диагностика межсетевого экрана: используйте команды netsh или политики групповой политики, чтобы детально проверять и изменять настройки WFP в режиме реального времени. Это может помочь более точно откалибровать правила.

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

Оцените материал
Добавить комментарий

Капча загружается...