У моего провайдера есть IP-TV(цифровое интерактивное телевидение по протоколу IP).Для просмотра каналов установил IP-TV Player.Долго мучался с настройками файрвола,чтобы все заработало.В итоге,методом проб и ошибок создал в глобальных правилах файрвола 2 разрешающих правила на входящие соединения.Во первых,разрешил все входящие по протоколу IGMP.Во вторых,входящие на порт 20000 по протоколу UDP с указанием масок подсетей.После этого плэйер стал работать нормально.
У меня,в связи с этим,возник вопрос.Не опасно ли разрешать все входящие по протоколу IGMP без указания конкретного порта,маски подсети и.т.д.)В журнале файрвола этих соединений-IGMP вообще нет!Получается он их изначально блокирует как сетевой флуд?
Хотел создать новую тему, но так как в этой описана похожая ситуация, задам вопрос здесь.
Настройки CIS по-умолчанию, за исключением блокировки всех входящих соединений через мастер скрытых портов (режим стэлс). При попытке просмотра IP-телевидения с помощью IP-TV Player’a (впрочем как и с помощью VLC media player’a) соединение не устанавливается, в журнале событий фаервола ничего не фиксируется. При этом все остальные приложения в интернет выходят нормально. После смены настроек через тот же мастер скрытых портов на “оповещать о входящих соединениях” картинка на плеере появляется, НО (!) запроса на входящее соединение нет! Вопрос об исходящем от плеера соединении задается, НО (!!) в активных сетевых подключениях CIS нет IP-TV плеера, в то время как он активно транслирует телевизионные каналы, качая мегабайты информации. Анимации иконки в трее тоже нет. Таким образом трафик при просмотре ip-телевидения проходит мимо фаервола! Судя по всему это баг CIS. Кто что думает? Есть смысл закидывать report в англоязычную версию?
P.S. Версия COMODO Internet Security 5.5.195786.1383. Операционка Windows XP Pro x86 SP3 Rus.
То есть, включая безопасный режим файрвола, правильно?
Тут уже интереснее, но, с другой стороны, входящего соединения при этом в каком-то смысле и в самом деле нет. О каком протоколе) речь при вопросе об исходящем от плеера (это в журнале)? Что при отсутствии плеера в активных соединениях показывает, скажем, TCPView?
Репорты никогда не помешают, но сначала, чтобы была печка, от которой плясать, можно ли Вас попросить о:
Скриншот глобальных правил и, если есть правила на плеер, то и их.
Проверить ещё вот такие моменты: Как изменится картина, если самым верхним глобальным правилом добавить явное “блокировать любые IGMP во всех направлениях” (лучше с логированием, разумеется), Что получится если в этом правиле заменить “блокировать” на “спрашивать”? Спасибо.
После снятия галочки интернет шлюза (ICS-сервер) ничего не поменялось. После установки настроек оповещения фаервола в очень высокий уровень тоже ничего не меняется (в безопасном режиме без изменений, в пользовательском режиме просто не один алерт а несколько для каждого порта).
Итак, теперь по порядку. Режим фаервола пользовательский, входящие соединения блокированы. Глобальные правила выглядят так
При попытке просмотреть какой-нибудь канал картинка на плеере не появляется. Теперь захожу снова в глобальные правила и меняю последнюю строчку с запретить и логировать на разрешить и логировать и о чудо - начинается передача данных. Меняю обратно на запретить - чудо исчезает. Заглядываю в журнал событий и вижу, что все это время блокировалось Windows Operating System по протоколу UDP.
Судя по всему CIS считает соединение плеера по протоколу UDP как соединение “без владельца”, то есть принадлежащие Windows Operating System. Если это изначально так и задумано в Comodo (хотя как по мне то это не совсем правильно), то как мне тогда создать правило для плеера таким образом, чтоб он работал, и одновременно чтоб режим стэлс остался включенным и отсеивал другие соединение “без владельца”?
P.S. Если самым верхним глобальным правилом добавить “блокировать любые ICMP во всех направлениях” то ничего не изменится, плеер продолжает работать (по протоколу UDP).
Вы уверены, что Ваш плеер не пользуется каким-то системными службами? Мы вот здесь недавно уже размышляли над похожим вопросом, правда не ясно, чем дело кончилось. Тогда, в принципе, можно допустить, что исходящие будут не от плеера лично.
Есть здесь какой-то глюк. Замечали уже, что CIS показывает не все соединения, а как он решает, что не показывать, пока не понятно. Тут интересно другое, почему плеер выступает как сервер на 1234-м порту. Этот вот этот вот плеер? Тем более, обычно CIS показывает все UDP вполне нормально, те же DNS.
Вряд ли так изначально задумано, но перепроверить стоит…
Я имел в виду IGMP, посчитал, что у Вас IPTV через него работает. Ну а блокировка ICMP конечно не даст ничего, да и IGMP тоже, раз у Вас по UDP.
Не уверен, вроде нет, но как это проверить? Кстати, точь-в-точь аналогичная ситуация с VLC Media Player’ом http://www.videolan.org. Если через любой из этих плееров смотреть видеопоток от чужого провайдера, Комодо отлично фиксирует передачу данных по протоколу TCP. Попробуйте, например, запустить этот http://tv.x-lan.net.ua:8015/musicbox на любом из плееров. Как только же я запускаю любой канал от своего провайдера, CIS передачу данных не показывает. Аналогичная ситуация была на другом провайдере, когда я смотрел видеопоток именно от него.
Да, это он.
Я не нашел в CIS как заблокировать IGMP, поэтому подумал, что это была опечатка. Кстати, а как блокировать IGMP в глобальных правилах? У меня такого протокола нет при выборе.
Заблокировал протокол IGMP так, как Вы показали и трансляция прекратилась. В логах фаервола все тот же Windows Operating System. Порылся на офф. сайте плеера и нашел: “В общем случае необходимо разрешить в системных правилах протокол IGMP (протокол управления подключениями к мультикаст-группам) и разрешить плееру любую TCP-активность (для скачивания списков каналов и телепрограммы) и UDP-активность (непосредственно для IPTV)”.
Включил режим “стелс” и добавил к нему 2 правила как на скриншоте. После этого плеер заработал.
Непонятно, почему CIS считает, что UDP соединение принадлежит Windows Operating System, а не ip-tv плееру… Учитывая, что поток информации по протоколу UDP может измерятся гигабайтами, думаю, этот трафик все-таки должен быть виден в активных подключения.
Раз уж эта тема вспомнилась в соседнем топике, кое-что добавлю. Если создать правило для WOS в правилах для приложений следующего содержания: Запретить и логировать IP входящие из MAC любой в MAC любой где протокол любой, а мастер скрытых портов перевести в режим Оповещать о входящих, то входящее UDP-соединение на порт 1234 все равно будет проходить без алетров, в мониторе активных соединений и в логе фаервола при этом ничего не будет. Если же такое блокирующее правило создать в глобальных правилах, лог покажет, что для WOS заблокирован UDP-входящий мультикаст на порт 1234.
Мастер скрытых портов у меня в режиме “стэлс”.
Создана сетевая зона для моего диапазона телеканалов и в глобальных правилах 2 разрешающих правила для входящих UDP на порт 1234 в эту сетевую зону. (2 правила, так как различные пакеты телепрограмм и радиостанций у меня идут в разных диапазонах IP).
liservik, у меня плеер работает без разрешения входящих по протоколу IGMP без проблем примерно минут 5 после запуска. Потом картинка зависает и звук пропадает. В логах фаервола - заблокированный IGMP.
Давайте разбираться.
