17 ответов в этой теме

[#user]

При использовании сервиса "ShieldsUP!" на сайте www.grc.com (Services->ShieldsUP!->All Service Ports) и Dr.Web SS 6.0 получаю такую картинку:

 f6.0.png   38,6К   78 Скачано раз

В случае же альтернативных файерволов (Kerio, встроенные файерволы Windows XP/7) все задействованные порты помечаются как "Stealth".

Настройки файервола Dr.Web следующие:
созданы только два правила - для Dr.Web Updater и Firefox. В обоих случаях разрешены только исходящие соединения.
Dr.Web Updater: UDP(53), TCP(80-83,443)
Firefox: UDP(53), TCP(80,443)

Все остальные соединения запрещены по-умолчанию: Packet filter - Deny all, Advanced - Block unknown connections.

В чем может быть причина?

[Пол Банки]

В случае же альтернативных файерволов (Kerio, встроенные файерволы Windows XP/7)

аутпост - все зеленое.

[Aleksey Strokin]

Все остальные соединения запрещены по-умолчанию: Packet filter - Deny all, Advanced - Block unknown connections.

Непонятно, если Packet filter - Deny all, то вообще ничего работать не будет.
После смены правил, перезапуск был?

[#user]

После смены правил, перезапуск был?

Да, конечно. И перезапуск и перезагрузка.

Непонятно, если Packet filter - Deny all, то вообще ничего работать не будет

Почему?
Разве описанные выше настройки не означают, что будет блокироваться все, что не разрешено двумя созданными правилами для Dr.Web Updater и Firefox?

P.S. Забыл уточнить, что служба DNS Client отключена, поэтому в соединениях для svchost.exe нет необходимости.

Сообщение было изменено #user: 14 Июнь 2011 - 14:24

[Aleksey Strokin]

Да, конечно. И перезапуск и перезагрузка.

Вы же хотите все порты закрыть, а некоторые системные порты такие системные..

Почему?
Разве описанные выше настройки не означают, что будет блокироваться все, что не разрешено двумя созданными правилами для Dr.Web Updater и Firefox?

Потому, что правила пакетного фильтра имеют более высокий приоритет, чем правила фильтра приложений.

[Borka]

Почему?
Разве описанные выше настройки не означают, что будет блокироваться все, что не разрешено двумя созданными правилами для Dr.Web Updater и Firefox?

Потому, что правила пакетного фильтра имеют более высокий приоритет, чем правила фильтра приложений.

А не наоборот?

[#user]

Потому, что правила пакетного фильтра имеют более высокий приоритет, чем правила фильтра приложений.

Тогда возникает вопрос почему все работает?

[Alexey Nevolin]

А не наоборот?

нет.

Потому, что правила пакетного фильтра имеют более высокий приоритет, чем правила фильтра приложений.

Тогда возникает вопрос почему все работает?

всё --- это что? как вы deny all поставили?

[Aleksey Strokin]

Потому, что правила пакетного фильтра имеют более высокий приоритет, чем правила фильтра приложений.

А не наоборот?

Нет, если пакетный фильтр, что то запрещает, значит такой пакет выкидывается. Т.е. если в пакетном фильтре нет не разрешений, не запрещений, то только тогда срабатывает фильтр приложений. Разумеется порядок проверок зависит от типа пакета. В исходящем, сначала проверятся app и потом пакетный фильтр(но если запрещено пакетным то выкинет всё равно, просто позже). В получаемом, сначала пакетный потом app.

Потому, что правила пакетного фильтра имеют более высокий приоритет, чем правила фильтра приложений.

Тогда возникает вопрос почему все работает?

Не тот какой надо интерфейс запрещён или запрещено но не правильно. Правильно это когда всем интерфейсам выставлено Deny All и настройки этого рулсета(Deny All) не менялись, и соответствуют изначальным.

[Borka]

А не наоборот?

нет.

Нормально... Было ж наоборот?

[Borka]

Потому, что правила пакетного фильтра имеют более высокий приоритет, чем правила фильтра приложений.

А не наоборот?

Нет, если пакетный фильтр, что то запрещает, значит такой пакет выкидывается. Т.е. если в пакетном фильтре нет не разрешений, не запрещений, то только тогда срабатывает фильтр приложений. Разумеется порядок проверок зависит от типа пакета. В исходящем, сначала проверятся app и потом пакетный фильтр(но если запрещено пакетным то выкинет всё равно, просто позже). В получаемом, сначала пакетный потом app.

Раньше же сначала проверялись правила для АФ и только затем ПФ?

[Aleksey Strokin]

Раньше же сначала проверялись правила для АФ и только затем ПФ?

Порядок проверок всегда определялся направлением, т.к. в принципе не возможно проверить исходящий пакет в пакетном фильтре до того как его сформирует tcpip.sys для данных полученных им из приложения(т.е. фильтр приложений будет в этом случае первым по любому). А вот, для входящего пакета первым будет пакетный фильтр, т.к. в этот момент говорить о приложениях рано.
Главное тут только то, что пройдут только те пакеты которые были разрешены обоими фильтрами(это если совсем упрощённо). Причём на пакетном уровне, всегда, сначала будут проверены правила пакетного фильтра и только потом будет проверка, нужен ли такой пакет фильтру приложений. Т.е. приоритет(не порядок проверки, см. выше) правил пакетного фильтра выше.

[Borka]

Раньше же сначала проверялись правила для АФ и только затем ПФ?

Порядок проверок всегда определялся направлением, т.к. в принципе не возможно проверить исходящий пакет в пакетном фильтре до того как его сформирует tcpip.sys для данных полученных им из приложения(т.е. фильтр приложений будет в этом случае первым по любому). А вот, для входящего пакета первым будет пакетный фильтр, т.к. в этот момент говорить о приложениях рано.
Главное тут только то, что пройдут только те пакеты которые были разрешены обоими фильтрами(это если совсем упрощённо). Причём на пакетном уровне, всегда, сначала будут проверены правила пакетного фильтра и только потом будет проверка, нужен ли такой пакет фильтру приложений. Т.е. приоритет(не порядок проверки, см. выше) правил пакетного фильтра выше.

Ага, ясно. Спасибо. Мы же за входящий траффик говорим.

[Aleksey Strokin]

Ага, ясно. Спасибо. Мы же за входящий траффик говорим.

Короче, дело ясное, что дело тёмное, но ведь работает же.

[#user]

Aleksey Strokin, спасибо за пояснения. Кажется разобрался с логикой работы файерволла Dr.Web.
По-поводу "Deny all" все верно - все соединения будут запрещены. Просто не учел, что нужно применять эти настройки не только в разделе "Packet filter", но и в разделе "Interfaces".

С контролем портов решил вопрос следующим образом:
помимо упомянутых двух правил в фильтре приложений, создал собственный набор правил в пакетном фильтре:
 pf.png   22,9К   31 Скачано раз
UDP(53)
TCP(80,443)
Внизу списка применено правило, запрещающее все остальные соединения по любому протоколу.

Теперь картинка выглядит так:
 grc2.png   37,39К   23 Скачано раз

[Пол Банки]

хм...интересно, а в будущем обычным пользователям эти правила нужно будет писать руками, чтобы получить такую же картинку?

[#user]

хм...интересно, а в будущем обычным пользователям эти правила нужно будет писать руками, чтобы получить такую же картинку?

Тут есть определенные нюансы. Разработчикам ведь нужно быть уверенными в том, что файерволл с настройками по-умолчанию не вызовет проблем с доступом в сеть какого-нибудь ПО на ПК обычного пользователя. Поэтому слишком уж закручивать настройки по-умолчанию вряд ли кто-то будет.

Да и не тот это компонент, который может быть особо полезен пользователю, не вникающему в тонкости настройки файерволла.

[Aleksey Strokin]

хм...интересно, а в будущем обычным пользователям эти правила нужно будет писать руками, чтобы получить такую же картинку?

В 7.0 бете ситуация с этим, уже значительно лучше, т.к. убрано много разрешений по умолчанию для многих портов(в пакетном фильтре). Теперь такие порты, для пакетного фильтра, будут открываться автоматически фильтром приложений, с учётом его правил. Хотя править настройки фильтра приложений при этом всё равно придётся, т.к. там по умолчанию приходится много разрешать. Впрочем, надо понимать, что доступность некоторых портов для скана, само по себе ещё не означает проблем с безопасностью, т.к. использовать уязвимость можно только в том случае, если данные с этих портов будут получены приложением(см. фильтрация на уровне приложений) и оно имеет подходящую уязвимость.