» Jetico Personal Firewall

А реально ли отменить для отдельно взятого exe проверку хеша?

Здравствуйте, начинаю разбираться в Jetico - очень нравится то, что всё гибко и прозрачно, но поначалу конечно сложновато.
Почитал эту тему, все 83 страницы конечно не осилил, но нашёл много полезного.

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

accept any svchost.exe

Цитата:

А что там переводить-то? Назначение портов?

именно назначения и хотелось бы
желательно поподробней и в одном доке

Ещё вопрос. Для чего нужны эти пакеты? Т.е. кто, кому и для чего их передаёт, если можно что-либо предположить.

UDP    incoming packet     192.168.254.100     192.168.254.255    138    138    
UDP    incoming packet     192.168.254.100     192.168.254.255    137    137

и насколько безопасно разрешить incoming packet между портами 137 и 138 для любых адресов? Я посмотрел на IANA что это порты сервисов имён и датаграм, но мне это не о многом говорит.

1ero
Это работа через NetBIOS по локальной сети.

Mylord666
спасибо! если правильно понимаю, это значит, что разрешить эти правила для любых адресов локальной сети безопасно. как это прописать в Jetico? network 192.168.0.0 / 255.255.0.0 ? Если я прав, то отвечать не нужно

1ero
Честно - не знаю. Никогда не использовал Jetico в локалке. Но по идее сетевые адреса в ЛВС - диапазон 192.168.0.1 - 192.168.254.254, 255.255.0.0. - маска подсети. Насчет безопасности локальной сети - тоже спорно.

2 1ero

Если сеть твоя, например, домашняя, из нескольких машин, занеси соответствующие IP в
трастед в settings.xml.

Например:

<var id="Trusted Zone">
<value>192.168.0.0/16</value>
...
</var>

Либо, если назначал IP руками, и, соответственно, знаешь их (так корректнее):

<var id="Trusted Zone">
<value>192.168.254.100</value>
<value>192.168.254.200</value>
и/или т.п.
...
</var>


Добавлено:
Что бы это значило: при соединении через ftp-клиент с ftp-сервером хостинг-провайдера, сервер запрашивает входящие пакеты по TCP.

Обычно в корне System IP Table стоит правило:

Отклонить предупреждение TCP входящий пакет все все TCP flags: SYN !ACK

В данном случае невозможно работать с данным ftp-сервером.


Если установить разрешающее правило для данного ftp-сервера вида:

Принять предупреждение TCP входящий пакет 1.2.3.4 10.1.4.146 20 все TCP flags: !( !SYN )

Где:
1.2.3.4 - ftp-сервер прова (условно)
10.1.4.146 - мой IP (ADSL соединение, не принципиально)

В данном случае - нормальная работа с 1.2.3.4

Примечание. TCP flags: !( !SYN ) - Означает: Включено обратное соответствие к: Флаги TCP - SYN - со снятым флагом; Остальные - все + Stateful Inspection - вкл.


Дело в том, что первый раз сталкиваюсь с подобным. Как правило, ftp-сервера (при подключении через ftp-клиент - пассивный режим) не запрашивают входящие пакеты по TCP.

Может кто сталкивался?

forser
Цитата:

сервер запрашивает входящие пакеты

Уточни, pls, как ты это себе представляешь. Дело в том, что пакеты не запрашиваются - они отправляются и принимаются (или не принимаются), а запрашиваются - соединения (ессно - посредством отправки пакетов). Ну так если речь идёт о входящем запросе соединения на порт 20 - сервер просто может быть так сконфигурирован, что не может работать в пассивном режиме, а для активного так и должно быть

forser
спасибо!

2 NothingAnother


Цитата:

Дело в том, что пакеты не запрашиваются - они отправляются и принимаются (или не принимаются), а запрашиваются - соединения (ессно - посредством отправки пакетов).

Естественно, - неверно выразился.


Цитата:

Ну так если речь идёт о входящем запросе соединения на порт 20 - сервер просто может быть так сконфигурирован, что не может работать в пассивном режиме, а для активного так и должно быть

Возможно, сейчас проверю на ftp-серверах других провайдеров, - отключу пассивный режим, соответственно, в ftp-клиенте.


Добавлено:
2NothingAnother


Цитата:

Ну так если речь идёт о входящем запросе соединения на порт 20 - сервер просто может быть так сконфигурирован, что не может работать в пассивном режиме, а для активного так и должно быть

Таки да... Аналогичная ситуация. Т.е., сервер работает только в активном режиме.

Чем это может грозить?...

forser
Да собственно, ничем дурным... Впрочем, таких серверов не так уж и много, и ты можешь привязать разрешающее правило к соотв. IP

2 NothingAnother


Цитата:

Да собственно, ничем дурным...

Спасибо, успокоил...

установил попробовать на свою голову
сразу отрубил инет и теперь не хочет удаляться - запускаю удаление и он думает бесконечно долго
как с этим бороться?

2NEW_MAKC
Эмоций много - толку мало...
Какую версию ставил? На какую ось? Какой антивир в системе?

NEW_MAKC
Знаю, проходили. В безопасном режиме сносится быстро. А в обычном необходимо какое-то шаманство, но уже не помню какое.

Натолкнулся на интересный баг в JPF2: что-то ребята перемудрили с Indirect Access.
Пример для иллюстрации:
Для начала запустил [more=проверку...]E:\>ipconfig /all

Настройка протокола IP для Windows

Имя компьютера . . . . . . . . . : barra-test
Основной DNS-суффикс . . . . . . :
Тип узла. . . . . . . . . . . . . : неизвестный
IP-маршрутизация включена . . . . : нет
WINS-прокси включен . . . . . . . : нет

Подключение по локальной сети - Ethernet адаптер:

DNS-суффикс этого подключения . . :
Описание . . . . . . . . . . . . : Realtek RTL8139 Family PCI Fast Ethe
rnet NIC
Физический адрес. . . . . . . . . : 00-50-FC-C5-25-6F
Dhcp включен. . . . . . . . . . . : нет
IP-адрес . . . . . . . . . . . . : 192.168.0.1
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз . . . . . . . . . . :

E:\>ping 192.168.0.2

Обмен пакетами с 192.168.0.2 по 32 байт:

Ответ от 192.168.0.2: число байт=32 время<1мс TTL=128
Ответ от 192.168.0.2: число байт=32 время<1мс TTL=128
Ответ от 192.168.0.2: число байт=32 время<1мс TTL=128
Ответ от 192.168.0.2: число байт=32 время<1мс TTL=128

Статистика Ping для 192.168.0.2:
Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

E:\>[/more]
Все работает... Теперь запускаю Adobe Acrobat Reader (под руку подвернулся), закрываю его.
Снова запускаю проверку - выскакивает окно с запросом:

даю режект и [more=получаю...]E:\>ping 192.168.0.2
Не удается обратиться к драйверу IP. Код ошибки 1.

E:\>ipconfig /all

Настройка протокола IP для Windows

Произошла внутренняя ошибка: Такой запрос не поддерживается.

Обратитесь к службе поддержки продуктов Microsoft за дальнейшей помощью.

Дополнительные сведения: не удалось запросить имя узла.

E:\>[/more]
т.е. глушится вся сетевая активность... Если убить запрещающее правило - все восстанавливается. Причем приложение/dll'ка может быть любое.
На Smokey's Security Forums эта проблема обсасывалась еще с 27 билда беты, но похоже, что разработчики алгоритм менять не собираются.

Но если сначала создать разрешающее правило, а затем исправить на режект, то приложение не сможет в инет выходить, но все остальные будут работать. Хотя смутно себе представляю, что такое Indirect Access

Из справки JPF2:

Цитата:

Indirect access type - type of indirect access to network
inject dll - application injected dll into networked application's address space
create remote thread - application created thread on behalf of networking application
write to other's memory - application wrote into networked application's memory
inter-process call - application performed inter-process call to networked application
parent process - application started networked application

А комбинация "разрешение -> режект", IMHO, если и будет работать, то до очередного перезапуска/перезагрузки. (Будет время - завтра попробую)

Jetico Personal Firewall 2.0.0.31
Скачать

Интересно будет он платным или всетаки нет ???

Abilon
Он уже платный. $/€ 39.95

Stamir

Не пруха.. Только хотел скачать,,, Спасибо

Не кисло он стоит. Им там не жирно ли будет???

У меня проблема.
Jetico 2.0.30 выдает запрос:
Network activity detected
Application: ...\HandyCache.exe
Activity type: send (0)
Local port: 8080
Remote address: 0.0.0.0:0



При этом любой вердикт (запретить/разрешить) все равно вызывает повторное появление запроса (причем неоднократное, иногда бывает до 20-30 запросов пока не закончатся).

Запрос возникает при серфинге web'а с Firefox'ом через прокси HandyCache, а AdMuncher используется для вырезания рекламы.
(Цепочка получается следующая [Firefox]->[AdMuncher:1101]->[HandyCache:8080]->inet)

Приложение в запросе может меняться, но это либо Firefox, либо AdMuncher, либо HandyCache (ну и Local port соответственно).

Попытка разрешения без Local port или Remote address, или их обоих результата не дает.

Момент возникновения запроса совершенно произвольный (нет определенных сайтов, времени работы).

Если отключить AdMuncher сообщения не появляются.

Есть ли какие-нибудь соображения по решению проблемы.

Jetico Personal Firewall 2.0.0.31 баги:

Не работает поиск в DC (прямое соединение)
Не устанавливается DAEMON Tools, и SPTD дравейра.
Теже яйца с алкоголиком...

откатился на 2.0.0.30

Jetico 2.0.0.32

Понимаю, что у меня проблема специфичная, но по
send (0)
есть хоть какая-нибудь информация, а то я нигде не могу найти, ни в мануале, ни на форуме Jetico.

4hex

Цитата:

Network activity detected

Application: %application%

Activity type: %event% (%parent_event%)
Local port: %local_port%
Remote Address: %remote_addr%:%remote_port%

Do you want to authorize it?

Соответственно:
send (передача) = %event% (событие)
(0) = (%parent_event%) (предок события)
Под 0 скорее всего подразумевается ядро или отсутствие предка.

XenoZ
спасибо, но тогда у меня еще вопрос: почему запрещающее или разрешающее правило не прекращает выдачу запроса?