Доброго времени суток! При использовании CFP3 столкнулся со следующей проблемой: даже если запрос, отправляемый в сеть, например, вэб-браузером, должен быть пропущен согласно настроенным правилам, пропускается он очень медленно. В результате у браузера истекает время ожидания ответа, и он прекращает загрузку страницы. После 2-3 попыток CFP всё-таки “прокашливается”, и страницу всё же удаётся загрузить. Причём после того как сайт загрузиться, дальнейшая навигация по нему проходит без проблем. Но если попытаться загрузить сайт с другого адреса (или с этого же адреса, но через некоторое время), то история повторяется. Аналогичная ситуация и с другими сетевыми приложениями (eDonkey-клиент, торрент-клиент и т.д.). С чем это может быть связано, и как это лечить?
Это очень похоже на Событие 4226.
Т.е. надо увеличить порог (не менее 100 поставить, а если очень активно используются осёл и торрент, то можно и больше).
В системных логах сообщений о событии 4226 всего 1-2. Так что навряд ли причина в нём.
А не может быть причина в “жёстких” правилах для svchost.exe и System? Я для них настроил следующие правила:
System
Allow TCP out
Source address: any
Destination address: 192.168.0.1, 192.168.0.2
Source port: any
Destination port: 1723
Необходимо для поднятия VPN
svchost.exe
Allow UDP out
Source address: 0.0.0.0
Destination address: 255.255.255.255
Source port: 68
Destination port: 67
Необходимо для поднятия сетевого подключения по ADSL.
Allow UDP Out
Source address: any
Destination address: 81.28.160.1, 81.28.160.111
Source port: any
Destination port: 53
Необходимо для работы с DNS-сервером провайдера
Allow TCP Out
Source address: any
Destination address: some.wsus.ru
Source port: any
Destination port: 80
Необходимо для работы с местным WSUS-сервером.
Все эти настройки подбирались экспериментальным путём: смотрел что куда ломится при соответствующих действиях и на основе этого составлял правила. И для System и для svchost.exe всё, что не соответствует этим правилам блокируется и логируется. Может быть я перекрыл этими правилами что-то нужное?
P.S.: кроме того в Global Rules я блокирую входящие ICMP echo requests и исходящие ICMP echo replys (вдруг это тоже какую-то роль играет =) )
Если есть срабатывания, то лучше пропатчить tspip.sys. В этом ничего страшного нет. Поставь 100 соединений (вместо стандартных 10) и понаблюдай. Обновления виндоса бывают восстанавливают этот файл, поэтому иногда стоит проверять.
Я патчил с помощью всроенной функции в программу xp-antispy - там всё по-русски и есть возможность всё вернуть назад, да и других полезных опций много.
Если Виста стоит, то тогда, наверное, другой патч нужен -
http://www.mydigitallife.info/2007/04/09/windows-vista-tcpipsys-connection-limit-patch-for-event-id-4226/
По vpn тут посмотри - Шапка для Comodo Firewall - [21] :: Тестирование :: Компьютерный форум Ru.Board
Правила для System и для svchost.exe нормальные. У меня там чуть больше (плюс ещё для обновления виндоса).
Блокировки ICMP, которые у тебя есть, никак не влияют.
Я всё-таки склоняюсь к 4226. Хотя может ещё какой-нить защитный софт стоит, который блочит/тормозит ?
я тоже думаю что у Вас идет сканирование вэб-трафика на зловредное активное содержимое. У меня бывают такие тормоза на некоторых сайтах, не совсем корректно работающих.
К этому моменту страница уже кэширована. Увеличьте размер кэша для браузера. Как вариант.
Стоит avast. Но раньше, когда стоял Outpost, avast таких эффектов не давал. Хвостов от Outpost-а тоже остаться не могло - система с тех пор переустанавливалась “с нуля”. Кроме того, avast я поставил уже после CFP, а подобные неприятные эффекты наблюдались сразу с того момента, как я поставил и настроил CFP.
Не думаю, что это кэш. Скажем, если я начну грузить forums.comodo.com, то получу вышеописанные тормоза. Но при переходах по топикам тормозов не будет, если не задерживаться в каком-либо топике. На некорректно работающие сайты, можно было бы подумать, если бы проблемы возникали только на некоторых сайтах. Но они возникают на всех, включая простые, как молоток, ya.ru и google.ru, где некорректно работать просто нечему.
По авасту не заню, не пользовался.
Ещё одна вещь есть: в журнале фаера не слишком ли много блокировок ?
Можно ещё попробовать отключить все опции в “Firewall” → “Attack Detection Settings” (у меня там стоит только галка на “Do protocol analysis”, но и её стоит попробовать снять), потом перегрузить комп и посмотреть будет ли результат от этого.
Baur,
Попробуйте запустить браузер, чтобы он как обычно начал “тормозить”, затем сразу посмотрите лог фаера (и дэфэнс+ на всякий случай).
Если лог ничего не показывает, можно полностью выключить фаер, как показано в последнем сообщении в часто задаваемых вопросах, чтобы убедиться, что проблема действительно из-за фаера.
Все понял. На форуме аваст по русски офф дистрибьютора на территории России есть ветка с подобной проблемой.
В антивирусе выключить вэб-сканер. Если трабла прекратится-смотрите в настройках во всех вкладках поставить по умолчанию. Какое правило для вэб-сканера в фаере?
Почитал ветки по таким проблемам и ужаснулся. Как люди забивают систему всякими драйверами от поделок типа спайбот и др… На борту фаервол с далеко нехилым HIPS, антивирус с антируткит-модулем и драйверов всяких антиспайваров накидают… Вот система на колени и становится…
barsukRed, у меня как раз SpyBot стоит и NOD32 2.70.39 и никаких тормозов… Правда, Defense+ выключен.
Сам процесс спайбота много весит, но систему не тормозит, причём и на слабых компах также без проблем работает с COMODO (правда, с двойкой).
Поставил порог 100. Не помогло.
Попробовал полностью отключить фаер по методике, указанной в FAQ, и антивирь до кучи. Проблема осталась. Видимо дело не в фаере. Завтра для чистоты эксперимента попытаюсь полностью снести фаер и антивирь. Посмотрю, что получится.
Не удаляя фаер и удалив все правила для аваста, переустановите антивирус. Иногда аваст при обновлении косо встает.
Таки дело оказалось не в фаере. И даже не в антивире. Проблема крылась в DNS: доменные имена разрешались в IP-адреса через раз (правда при использовании nslookup всё было нормально). До тех пор, пока адрес ресурса висел в DNS-кэше, проблем при работе с ним не наблюдалось. Всё упиралось в то, что у мну на WinXP стояло обновление KB951748, которому для нормальной работы требовалось соответствующее обновление на DNS-сервере, которого у провайдера не стояло. Помог откат этого обновления.