Правила вихідного брандмауера Windows 7 дозволяють правилу CryptSvc не збігатися


3

Я використовую брандмауер Windows 7 з увімкненою фільтрацією на вихід. Брандмауер Windows не надає інтерфейс користувача для нових підказок вихідного з'єднання, він просто блокує їх. Система керування брандмауером Windows вирішує це за допомогою методу вирішення - це дозволяє реєструвати журнал аудиту відмов падіння пакету / з’єднання, відстежує журнал безпеки нових записів та при необхідності відображає підказки.

Я витратив час на розробку списку вихідних дозволених правил для всіх системних служб і додатків, які потребують вихідних з'єднань. Брандмауер Windows може орієнтуватися на конкретні сервіси в svchost.exe, що дозволяє досить тонко контролювати. Я натрапив на лише дві речі, де це не працює - Мережеве відкриття та Криптографічні послуги.

Увімкнено таке правило:

netsh advfirewall firewall add rule name="Windows Cryptographic Services"
  program="%SystemRoot%\System32\svchost.exe" service=CryptSvc 
  protocol=tcp remoteport=80,443 dir=out action=allow

Однак я все ще отримую блоки, що походять від svchost.exe, що розміщує CryptSvc, намагаючись встановити вихідні http-з'єднання, щоб перевірити сертифікати тощо. Я навіть використовував sc config CryptSvc type=ownдля виділення служби у власний контейнер, щоб підтвердити, що справді CryptSvc робить ці запити. І навіть тоді правило все одно не відповідало б. Є багато інших правил з тією ж структурою, просто різні цільові служби, де все працює чудово.

Поки що я не зміг знайти задовільного рішення. Якщо дозволити "CryptSvc" все "все одно не зрівняється. Обсяг повинен бути принаймні "всіма службами", щоб він відповідав, і це занадто широко. Я можу додати правило ігнорування svchost.exe у WFC, але це, знову ж таки, занадто широко для мого вподобання. Я вважаю за краще систематичне рішення.

EDIT: При спробі редагування мого правила брандмауера з'являється поле попередження:

Служби Windows обмежені правилами, які дозволяють лише очікувану поведінку. Правила, які задають хост-процеси, такі як svchost.exe, можуть не працювати як слід, оскільки вони можуть суперечити правилам загартовування служб Windows.

Ви впевнені, що хочете створити правило, яке посилається на цей процес?

Можливо, це «загартовування» заважає механізму брандмауера для ідентифікації вихідної послуги.


1
Гм, я спробую, не впевнений, чого цього досягти, хоча журнали чітко говорять, що він спрацьовує при спробах підключення до MS серверів на порт 80.
theultramage

Метою є належна фільтрація вихідної пошти, при цьому всі основні сервіси, які потребують доступу до мережі, покриваються відповідними правилами брандмауера. Вбудований продукт брандмауера Windows не надає інтерфейс користувача для нових підказок вихідного з'єднання. Якщо ввімкнути режим заборони за замовчуванням, ви навіть не будете знати, що намагається підключити (і коли), якщо ви не використовуєте auditpol.exe для ввімкнення журналу. І навіть тоді вам доведеться просіяти всі мотлохи в журналі безпеки. Ось де WFC заходить, він робить це для вас. Я тримаюсь осторонь від сторонніх продуктів брандмауера, мене раніше спалювали.
thetratramage

Що я роблю при використанні WFC - це перевести його в режим сповіщень, тому щоразу, коли щось хоче вийти, я отримую спливаюче вікно, де я можу це дозволити або заборонити, це дозволяє більш простим способом створювати правила, а не користувальницькі інструкції ті.
Моаб

1
Проблема полягає в тому, що правило дозволу CryptSvc не узгоджується, незалежно від того, як я його визначаю, тому кожен раз, коли щось намагається зробити CRL / OCSP, воно все одно блокується, і я отримую спам із підказками. Моє поточне вирішення - це блокувати їх (погано для безпеки!) Та замовчувати svchost.exe у WFC.
thetratramage
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.