scvhost и 53 порт

Второй день как юзаю КОМОДО. Все вроде работает, но файервол блочит все обращения на 53 порт на моем компе который по соместительсву еще и гейт для баленькой домашней сети на 3 компа. Установил scvhost как Trasted Application, добавил локалку в allowed:

Allow All Incoming Requests If The Sender Is In [Local Network]
Allow All Outgoing Requests If The Target Is In [Local Network]

перенес в верх списка.

Открывал 53 порт спициально для айпишника внутри сети. Пробовал. Блочит и все тут.

Без этого как понимаем не рабоатет инет внутри домашней сетки.

Есть мысли?

Спасибо.

День добрый.
Какая версия Comodo?
Если отключить фаер (если 3-я версия: щелкнуть мышкой по значку в трее → firewall → disabled), блокируется ли соединение? Что показывает лог сразу после того, как соединение было заблокировано?

У Вас именно такое название процесса или Вы имели ввиду svchost.exe? Для svchost.exe нужно строго прописать IP DNS Servers для 53 порта.
В противном случае речь идет о блокировании и редиректе зловредным процессом запросов на DNS Servers…

Постораюсь отвечать четко чтобы не тратить ваше время:

  1. Версия: 3.0.16.295
  2. Если задизейблить то работает DNS и состветсвенно локалка с инетом.
  3. Смотрел лог здесь Firewall->View Firewall Events, строчка блокировки выглядит так:

Application
c:\windows\system32\svchost.exe

Action
Blocked

Protocol
UDP

Source IP

192.168.0.5

Source Port
1044

Distination IP
192.168.0.1

Distination Port
53

1.vchost.exe
2. “строго прописывать” можно подробнее? не уловил как это сделать.

Спасибо.

Ваш компьютер заражен. Утверждаю точно. Даже зловред знаком. Могу предложить действовать по этому алгоритму. Выложите логи здесь или мне в личку. Постараюсь Вам помочь. Если,конечно ,Вы этого хотите. :slight_smile:

Shu,
Напишите пожалуйста, действительно ли оказалось, что ваш компьютер заражен?

Если с машиной все в порядке, но по-прежнему блокируется соединение, можете попробовать вот что:

firewall->advanced->firewall behavior settings->alert settings->поставьте галку “This computer is an internet connection gateway…”

затем:

Если не поможет, firewall->advanced->attack detection settings->убрать все галки. Затем попробовать еще раз.

Если перестанет блокироваться, надо будет для scvhost.exe вместо Trusted Application подобрать определенные правила.

Нашел все что нужно, прочитал. Сделал как надо вируса нет. Есть опечатка. svchost.exe теперь все буквы на месте.

Если Вы ничего не нашли в логах(если умеете читать логи HijackThis и AVZ) или АВП не находят вирусов-это еще не значит что вирусов нет. КОМОДО ОТЛИЧНО СПРАВЛЯЕТСЯ С СОЗДАНИЕМ ПРАВИЛ В АВТОМАТИЧЕСКОМ РЕЖИМЕ. Я работаю с этим фаером очень давно и никогда автоконфигурирование не приводило к отказам. Исключение-разрешение входящих. Это надо делать вручную.
Единственной предпосылкой к Вашему случаю-руткит.
Но если не хотите-хозяин-барин. Тогда-удачи! :slight_smile:

Спасибо, помогло.

Вируса нет. Все равно спасибо за желание помочь.

goodbrazer, не стал открывать новый топик.
В продолжение этого.
Пытался настроить версию 17, но так и не смог её заставить разрешать сетевый соединения для svchost.exe (процесс именно такой). Соединения нужны для DNS и для DHCP.
Фаер блокирует этот процесс и всё.
Defense+ отключён. Комп перегружал не раз, но для данного процесса запросов нет - просто тупо блокируется.
Разрешал полностью все соединения ему, перегружал - ноль эффекта.
Но вот не помню стояла ли указанная галочка в Behavior Settings. Утверждать не буду, но вроде бы всё там было включено.
Помогло мне только полное удаление версии 17 и установка 16.
Версию 18 пока не пробовал, буду в выходные смотреть, не раньше.
Если есть ещё какие-нить мысли, то отпишите, пожалуйста.
У меня провайдер предоставляет выход в интернет через vpn (Корбина, если вдруг чем поможет).
P.S. В чистоте компьютера уверен.

Добро пожаловать, WIGF

Попробуйте поставить 3.0.18 с “0”, а не обновить с помощью внутренней программы перед попыткой. При установке выберите “basic firewall” (правда не знаю, можно ли в этом случае включить D+ позже, в случае необходимости).

Для начала простой, но очень важный вопрос: есть ли проблема, когда Comodo не установлен? И еще один: есть ли проблема, когда Comodo выключен с помощью иконки в трее (firewall->disabled)?

Переведите экран в режим custom policy, удалите все глобальные правила, сделайте svchost.exe и system доверенными приложениями, убедитесь, что Windows Operating System нет в списке приложений (удалите ее из списка, если она будет там).
Также проверьте, влияет ли указанная галка в behavior settings на блокировку svchost.exe.
Еще надо попробовать убрать галки (6 опций) в настройках attack detection settings.

На каждом этапе проверяйте лог на наличие блокируемых элементов.

P.S.: если у нас все же никак не получится настроить, напишем bug report, если вы не против (в этом случае мне нужна будет некоторая дополнительная информация).
P.S.2: Английский знаете?

goodbrazer, спасибо за ответ и за советы :slight_smile:
Постараюсь сейчас ответить на всё, на что могу, пока не пробовал ставить версию 18, об остальном отпишусь в выходные или после них.

  1. Ставил бы обновлением, но раз вы написали, то попробую сразу ставить с нуля. Defense+ я отключил и при прошлом обновлении также выбрал только фаер. Сейчас тоже без фаера буду ставить.
  2. Пока была версия 16, проблем с DHCP и DNS не было. Установил обновление, перегрузил комп… и всё, пошли блокировки.
  3. Пробовал в режимах TwS, Training и Disabled. Блокировки были. А вот Custom, честно говоря, не пробовал.
  4. Правил не было для svchost, были правила только для самого CFP и для Windows Updates. Вторую позицию я запретил полностью и стал создавать правила для других приложений (сначала, само собой, прописал зоны, порты и политики и на их основе уже правила для приложений делал).
  5. В attack detection settings стояли только две галки: на фрагментированных пакетах и на анализе протокола. Потом отключал на всякий случай фрагментированные, поскольку у меня, как уже говорил, через vpn интернет, но не помогло. Раньше работала и двойка и тройка с предыдущими релизами (14-16) с данной галкой.
    Увеличивал порог срабатывания UDP-флуда до 1000 пакетов, т.к. без данной опции режется IPTV. Остальные не пробовал увеличивать за ненадобностью (ни разу не было срабатываний).

Больше действий никаких вроде бы не предпринимал. В логе были блокировки процесса svchost.exe по исходящим DNS на DNS-серверы провайдера и по исходящим DHCP на 255.255.255.255.

Для полноты информации: помимо CFP мониторят у меня на компе NOD32 2.7 и Ad-Aware 1.06, т.е. других приложений, кроме CFP, которые могли бы ненароком блочить сетевые соединения нет.

По баг-репорту я не против, но сначала все возможные варианты изучу и испробую, а если не поможет, то тогда уже будем в этом направлении работать.

P.S. Английский не знаю в том виде, в котором бы хотелось, т.к. был другой язык и в образовательные годы… да и было это давно… Но с компьютером давно знаком (уже лет 20), поэтому волей-неволей компьютерный английский понимаю без проблем, а вот разговорный только в плане чтения.
В общем, умею читать, а сказать ничего не могу и глаза такие умные-умные ;D

Проверьте пожалуйста, когда Comodo будет полностью удален, если все работает, поставьте фаер с 0 и, не меняя никаких системных настроек и не меняя список автозагрузки (NOD32 и т. д.), проверьте работу vpn-dhcp с теми настройками, которые я показал в предыдущем сообщении.

Возможно, что в вашем случае блокирование происходит запрещенной группой Windows Updates, т. к. svchost.exe входит в эту группу. Хотя, если такие же настройки были на 16… не знаю, но стоит проверить:
В дополнение к предыдущим рекомендациям: удалите группу windows updates из правил для приложений на время тестирования.

И кстати, у меня есть сильное подозрение, что эту группу вообще не надо держать в network security policy, если фаер в custom policy.

Добавлено: на баг трэккере нашел похожий случай. Блокировался svchost на 255.255.255.255, несмотря на разрешающие правила. Выяснилось, что фаер работал правильно и блокировал группу Windows Updater Applications. Ситуация была разрешена, когда svchost.exe был удален из состава группы.

goodbrazer, сам в предыдущем сообщении написал о Windows Updater и закралось подозрение, что в нём весь секрет. А потом и вы об этом же написали. Отвечат сразу не стал, решил ответить только после проверки на компутере.
Итак, отчёт “Как я провёл лето”: :slight_smile:

  1. Дошел до перестановки фаера только сегодня с утра. Первым делм проверил действующую конфигурацию: там в AR была группа приложений Windows Updater Applications и она была заблокирована. Помимо этого имелись правила для svchost.exe по исходящим DNS и DHCP. Всё работало, но возможно возникла бы проблема при обновлении IP-адреса (например, при вытаскивании, а потом обратном втыкании шнура), но я так и не попробовал этого…
    Указанная ранее галочка в настройках “This computer is an internet connection gateway…” стояла как я и думал.
  2. Вытащил сетевой провод → стёр версию 16 → перегрузил → поставил версию 18 (только фаер) → перегрузил → вставил сетевой провод → сеть работала → зашёл в GUI
    Небольшое отступление.
    А вот тут непонятка вышла: Defense+ был включен, хотя я от него отказался при установке. Нехорошо. “Тефаль всегда думает о нас ?” ???

    Продолжаем:
    → перевёл фаер в Custom Mode → заблокировал Windows Updater Applications-> перетыкнул сетевой провод и сеть не заработала ! → удалил из списка Windows Updater Applications → перетыкнул провод → запрос от фаера по разрешению DHCP, само собой, я его разрешил → сеть заработала
  3. Импортировал конфигурацию от вервии 16. Всё сохранилось, всё работает. Правило по Windows Updater Applications удалил из списка. Комп перегружал, кабель перетыкал. Всё работает.

В общем, терпения мне прошлый раз не хватило. Секрет, действительно, был в этой группе Windows Updater Applications.
И, возможно, и раньше так же всё блокировалось бы, но просто я успевал получить настройки, а только потом блокировал данную группу и провод после этого не перетыкал…
Хотя, я вручную добавлял правила по DNS для процесса svchost.exe и они сразу начинали действовать в версии 16, а версии 17 не действовали. При этом я разрешающие правила (для svchost.exe) ставил и в 16, и в 17 версиях раньше запрещающего (по Windows Updater Applications). Возможно заявленные глобальные изменения в 17-й версии как раз и касались в том числе и подобных случаев: т.е. возможно раньше при нахождении разрешающего правила в AR проверка далее в AR не производилась и сразу проверялись GR, а теперь даже при нахождении разрешающего правила в AR по какому-либо приложению проверка продолжается, но по другим приложениям (группам приложений), а только потом идёт проверка в GR.

WIGF,

Ну что же, хорошо, что все стало на свои места. Действительно, могли изменить принцип обработки правил в 17 по сравнению с 16.

Да, есть такая проблема сейчас, забыл сказать; разработчики в курсе. Как временное решение: перевести D+ в disabled.

А если я для SVCHOST поставлю правило Outgoing Only то это очень критично или более-мение нармалёк??? Потому что я вообще не разберусь как эти отдельные правила создавать что рекомендуют в “часто задаваемые вопросы”.

Обычно так и делают. Для некоторых фаерволов для SVCHOST.ехе надо разрешать неограниченно исходящие. Это нужно для корректной работы того же самого svchost.exe Только нужно внимательно следить за правильным адресом этого файла: C:\WINDOWS\system32\svchost.exe
Более узкие правила для svchost.exe делают более квалифицированные пользователи,так как некорректно составленное правило может привести даже к неработоспособности соединения с инетом.