» Jetico Personal Firewall

CaptainFlint
А если попробовать:
sc start "Jetico Personal Firewall server"
и сразу, подряд несколько:
sc queryex "Jetico Personal Firewall server"
какая информация на выходе?
По наглому если попробовать, что то вроде:
sc config "Jetico Personal Firewall server" binpath= "C:\Program Files\Jetico\Jetico Personal Firewall\jpfsrv.exe" start= auto
в общем с sc поиграться, на предмет запуска сервера, или хоть ошибку получить.
Есть подозрение, что удаление с остановленным сервером некорректно. Хорошо бы запустить хоть как то и удалить.
Ещё гляньте ветвь:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
bc_hash_f
bc_ip_f
bc_ngn
bc_pat_f
bc_prt_f
bc_tdi_f
Bcfilter
BcfilterMP
bcftdi
Jetico Personal Firewall server
Вообще должно удаляться само, но мало ли...

Dimitr1s

Цитата:

А если попробовать:
sc start "Jetico Personal Firewall server"
и сразу, подряд несколько:
sc queryex "Jetico Personal Firewall server"
какая информация на выходе?

Я загнал их в одну команду (через &&), и даже в этом случае queryex говорит, что сервис остановлен. Слишком быстро вылетает.


Цитата:

По наглому если попробовать, что то вроде:
sc config "Jetico Personal Firewall server" binpath= "C:\Program Files\Jetico\Jetico Personal Firewall\jpfsrv.exe" start= auto

Так у него в точности такие параметры и выставлены.


Цитата:

в общем с sc поиграться, на предмет запуска сервера, или хоть ошибку получить

Так ошибки нет, я ж с самого начала написал это. Код возврата — ноль. Подтверждается тремя проверками: во-первых, при запуске через mmc говорится не о падении с ошибкой, а что служба запустилась и завершилась; во-вторых, тот же sc queryex сообщает, что код возврата остановившегося сервиса нулевой; и в-третьих, я натравил Process Monitor на слежение за jpfsrv.exe (ещё в самом начале экспериментов, чтобы понять, какие конкретно файлы или ключи реестра ему могли не понравиться), и тот тоже показал код завершения ноль.


Цитата:

Ещё гляньте ветвь:

Это само собой. За ней я тоже следил с самого начала, когда реестр чистил.

CaptainFlint
Тогда, чтоб исключить полностью остатки сервера Jetico, могу предложить ещё такой вариант:
Перед удалением, сохраните куда-нибудь jpfsrv.exe.
После удаления после чистки всего вышеперечисленного, откройте jpfsrv.exe плагином Тотала - fileinfo и удалите все принадлежащие Jetico ключи, на вкладке Aktivex/OCX - перечисленные после префикса *uuid(. Если после этого не заработает, с большой долей вероятности можно искать другую причину.

Dimitr1s

Он полностьб вычищается тем же Revo Uninstaller даже его Free версией 1.90. Буквально на днях чистил знакомым машину от того что им наставил парень от провайдера. В итоге у людей и звука не было - малый им звуковой чип просто выключил - "А это вообще лишнее!". А все остатки программ, в .ч. и неудачно установленной "связки" CIS+JPFP+KIS (это надо было доматься!!!)т Revo вычистил с одним перезапуском. Дальше оказалось достаточно только в TCP/IP DNS прописать и всё заработало. Именно с 2.1.0.8.

Возможно ли в Jetico разрешить доступ для определённой группы пользователей сети к определённым сайтам в интернете, а все остальные сайты запретить, а также блокировать трафик по доменному имени адресата/получателя и по номеру порта?

veikim

Цитата:

разрешить доступ для определённой группы пользователей сети к определённым сайтам в интернете, а все остальные сайты запретить,

Можно указывать различные файлы конфигурации и ограничить права на редактирование/просмотр.
Цитата:

блокировать трафик по доменному имени адресата/получателя и по номеру порта?

Нет, имена пока не резолвит.

Dimitr1s

Цитата:

После удаления после чистки всего вышеперечисленного, откройте jpfsrv.exe плагином Тотала - fileinfo и удалите все принадлежащие Jetico ключи, на вкладке Aktivex/OCX

Проверил — всё очистилось само при деинсталляции.
Прогнал ещё и через Revo — результат тот же, то бишь никакого.

CaptainFlint
Если дело не в Джетике, попробуйте "копать" COM.
Если малыми силами, то попытаться перерегистрировать:
comuid.dll
COMRes.dll
Comsvcs.dll
ole32.dll
oleaut32.dl
Если не малыми, то переустановить COM, я когда то делал по руководству отсюда (2 часть).
Ещё м.б. это:
Цитата:

деинсталлировал Касперского

пройтись ремувером от них самих. В нынешнем исполнении - та ещё поделка.

Dimitr1s

Цитата:

Если не малыми, то переустановить COM

Попробовал по второму сценарию — не помогло. Третий (с полной перегенерацией каталога) пробовать нет смысла, т.к. написано, что надо переустановить все программы с COM — в моём случае это почти равносильно переустановке системы.


Цитата:

пройтись ремувером от них самих.

Не помогло. Да и не должно было, виновник-то не Каспер был.

CaptainFlint
Тогда, выходит, всё-таки остался драйвер VMware, который запускается при старте системы и ставит "ловушки" - чудес то не бывает. Попробуйте отловить способов масса. Как крайний вариант, если ничего не помогает, после резервирования, можно включить Driver Verifier (verifier.exe) на все драйверы Джетико (но может не сработать, а Verifier угробит систему "с концами"). По идее, при сбое старта сервера, должен выпасть "синяк" с указанием в дампе виновников. Ещё, а проделки "засранчегов" на 100% исключаете (когда ставили VMware, там: кейгены, кряки), м.б. прогнать AVZ, CureIt! на всякий случай (если на 100% не исключаете)? AVZ может заодно дать наводку на оставшийся драйвер VMware (если он есть и работает).

Dimitr1s
CaptainFlint

Стоп, а почему бы не воспользоваться вот этой штукой - Pserv.CPL v2.7 - старушка прекрасно работает и на Windows 7, а что нам важно это умеет удалять и корректировать любые записи драйверов и демонов. Как возможный инструмент я её не стал бы сбрасывать со счетов. Благо в ней можно получить достаточно подробную информацию о любом драйвере/демоне и его зависимостях, да и если что поправить ошибки. Это чисто её работа.

Dimitr1s

Цитата:

Тогда, выходит, всё-таки остался драйвер VMware, который запускается при старте системы и ставит "ловушки"

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


Цитата:

Как крайний вариант, если ничего не помогает, после резервирования, можно включить Driver Verifier

Это слишком жёсткий вариант, виндовой системе восстановления я не доверяю (пробовал не раз, в большинстве случаев помощи от неё было, как от козла молока), а для образа всей системы у меня нет достаточного свободного места.


Цитата:

Ещё, а проделки "засранчегов" на 100% исключаете (когда ставили VMware, там: кейгены, кряки)

Кейгенов и кряков к ней не запускал совсем. К другим программам — случалось, но очень давно, с тех пор неоднократно прогонял полную проверку тем же Каспером (в том числе в оффлайне, с загрузочного сидюка), да и вообще стараюсь следить за происходящим на компе. Лишних процессов нет, драйверы, вроде, все по делу, RootkitRevealer ничего плохого тоже не обнаруживает, разнообразных необычных активностей в системе не отмечается. Если зловред и сидит, то какой-то просто сверх-законспирированный, практически не распространённый и чрезвычайно аккуратный в работе. Думаю, шансы на это хоть и теоретически ненулевые, всё же достаточно низки, чтобы их не учитывать.

CaptainFlint

Цитата:

...виндовой системе восстановления я не доверяю...

Кто ж ей доверяет . Нет, тут другой функционал, почитайте если интересно. Если дело в Джетико, включение Verifier'а на её драйвера, при сбое (а тут явный сбой) по идее вызовет бсод, а в дамп падения запишутся все участвовавшие модули. Просто, Вам сейчас нужно выявить кто виноват, а иначе можно гадать долго.
Цитата:

Да и не должно было, виновник-то не Каспер был.

Забыл ответить... Виновным могло стать его удаление, а не он сам. Гремучая смесь получилась - установка/удаление VMware, удаление Касперского, установка/удаление Jetico 2.1.0.9, плюс по видимому ещё запускали "авто_чистилки". Если повреждения в COM+/DCOM, ИМХО проще переустановить систему, чем исправить.

CaptainFlint

Я думаю, что выше вероятность неправильной установки ACL инсталлером Джетики. Случайный сбой либо ошибка программистов. Можно попробовать выставить запуск её служб не от учётной записи LOCAL SYSTEM - её пароль нам не известен, а от учётной записи суперпользователя (т.е. полного админа). Такая настройка часто позволяет решить проблему с запуском драйверов и демонов.

Victor_VG

Цитата:

Я думаю, что выше вероятность неправильной установки ACL инсталлером Джетики.

ACL чего, jpfsrv.exe или langfile2.dll? Тогда бы сервер не пытался запускаться. Здесь:

Джетика тоже ничего не меняет.

CaptainFlint

Цитата:

Ни единого вм-варьного драйвера у меня физически нет на компе.

Ещё мысль. А ни каких хитрых руткитов (в хорошем смысле) VMware не ставит? Тогда тяжело обнаружить, к примеру сохраняется в по окончании сессии каждый раз под произвольным именем и т.п., способов много.

Dimitr1s

А зачем ей менять? Просто из-за ошибки в инсталлере SCM неверный ACL создаёт и при запуске это вылезает блокировкой от lsass. У меня такие вещи уже были. А лезть в БД SAM с её недокументированным форматом? Тут вообще дело гиблое. Хотя ещё одно место есть - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum там остаются следы удалённых драйверов и демонов. Вот там и по всей подветке HKEY_LOCAL_MACHINE\SYSTEM\ControlSet0хх я бы поискал что осталось руками - не доверяю я автоматике - или ничего не находит, или лишнее прихватывает. Железяка, что с неё взять?

Dimitr1s

Цитата:

Кто ж ей доверяет . Нет, тут другой функционал, почитайте если интересно.

Да нет, я не о том. Что делает Driver Verifier я примерно знаю, но меня напугала фраза:

Цитата:

(но может не сработать, а Verifier угробит систему "с концами")

Или под "угробом" понимался всего лишь BSOD? Потому что если система потеряет работоспособность, это будет очень и очень плохо. А если речь только о BSOD'е, то попробую.


Цитата:

Виновным могло стать его удаление, а не он сам. Гремучая смесь получилась - установка/удаление VMware, удаление Касперского, установка/удаление Jetico 2.1.0.9

Если честно, звучит сомнительно. Началось-то всё только с установки "твари", а все последующие действия были лишь попытками исправить ситуацию, которая уже имела место на компе. Как-то маловероятно, чтобы эти действия могли одновременно и устранить исходную причину, и добавить новую, с первой причиной не связанную, но дающую абсолютно такой же эффект на Джетику.


Цитата:

плюс по видимому ещё запускали "авто_чистилки"

Ни в коем разе! Токмо ручками.


Цитата:

Если повреждения в COM+/DCOM, ИМХО проще переустановить систему, чем исправить.

Вот я к тому же выводу постепенно прихожу. Но столько свободного времени у меня пока нет.


Victor_VG

Цитата:

Можно попробовать выставить запуск её служб не от учётной записи LOCAL SYSTEM - её пароль нам не известен, а от учётной записи суперпользователя (т.е. полного админа).

Хм… Попробую, но мне казалось, что системная учётка имеет больше прав, чем админская. Во всяком случае, по умолчанию админу недоступны каталог System Volume Information и запись в реестр в ветки HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum, а SYSTEM'у — доступны.


Dimitr1s

Цитата:

Ещё мысль. А ни каких хитрых руткитов (в хорошем смысле) VMware не ставит?

Не вижу причин, зачем это могло бы ей понадобиться. Это ж не DRM всё-таки. Опять же, RootkitRevealer молчит (конечно, это не гарантия, но, думается, для его обхода пришлось бы применять какие-то крайне нетипичные меры — вряд ли разработчики стали бы этим заморачиваться, выгоды нет).


Victor_VG

Цитата:

Хотя ещё одно место есть - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum там остаются следы удалённых драйверов и демонов. Вот там и по всей подветке HKEY_LOCAL_MACHINE\SYSTEM\ControlSet0хх я бы поискал что осталось руками

Если можно, чуть подробнее: что конкретно искать? Остатки следов драйверов Джетики, Каспера и Вм-твари я оттуда уже вычищал, но ACL не проверял. Какой именно ACL имеется в виду?

CaptainFlint

Тут вот что иногда бывает: обычно драйвера/демоны стартуют с системной учёткой, но я встречался со случаями когда из-за неверно заданного пароля для этой учётной записи они не могли стартовать - их процессы завершал lsass через scm. Как следствие наблюдался сбой запуска зависимых драйверов/демонов и иногда целых подсистем. Вот в таких случаях мы даём команду на запуск проблемного компонента не от имени системы, а от имени админа - ведь его пароль мы знаем, и его уровня привилегий обычно достаточно для их запуска и работы. А искать надо в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root записи удалённых уже устройств/демонов - они не будут иметь пары в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services все нужные нам записи в этом подключе начинаются с шаблонного имени LEGACY_ нашёл непарную - выставляй на неё полные права доступа с учётом подключей и удаляй смело - она запросто моджет всю систему тебе на уши поставить.

CaptainFlint

Цитата:

Или под "угробом" понимался всего лишь BSOD?

Если включить только на драйвера Джетико, то с большой вероятностью да, только BSOD. После эксперемента, обязательно не забыть выключить.
Цитата:

Ни в коем разе! Токмо ручками.

Смутило это:
Цитата:

Прогнал ещё и через Revo

Дело в том, что большинство чистилок из ...Enum\Root не удаляют, за отсутствием прав - а рапортуют об обратном.
Цитата:

а все последующие действия были лишь попытками исправить ситуацию, которая уже имела место на компе.

Если вернуться к началу, то версия 2.0.1.9 сама по себе, после не корректного удаления, даёт описанный эффект - установленные после её удаления, предшествующие версии, не работают по причине сбоя сервера. У меня на ХР была ситуация точь-в-точь. Установка/удаление рабочей версии, с перезагрузкой, решала проблему. Я к чему: в тот момент удаление/установка Касперского, по большому счёту добавляющему/изменяющему параметры в большинстве тех же ключей (да ещё, плюс, берущему некоторые под защиту от записи), что и Джетика могло "закрепить" проблему. Если пробовать то только с полностью удалённым антивирусом (простое отключение ни чего не даст).
Цитата:

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

Не знаю, не пользуюсь. Просто спросил, как один из вариантов.
Victor_VG

Цитата:

Просто из-за ошибки в инсталлере SCM неверный ACL создаёт

Я и спросил ACL чего каталогов, файлов, ключей реестра. Если каталогов/файлов, то ответил - Джетика точно не меняет. Если реестр, то CaptainFlint писал, что все ключи удалил вручную, в том числе и из ...Enum\Root.
Цитата:

...нашёл непарную - выставляй на неё полные права доступа с учётом подключей и удаляй смело...

Прежде чем такое советовать, у себя сначала так сделай.

Dimitr1s

Так и делаю всегда. Не проверив бы не сказал.

Victor_VG

Цитата:

Не проверив бы не сказал.

Я бы тоже. Как самый безобидный пример, программы Русиновича - пишут параметры в:
...\Enum\Root\ типа: LEGACY_REGMON*, LEGACY_PROCEXP*
При этом не всегда создавая дубликатов в:
...\Services\
Конкретно в этом случае ничего не случится, если удалить - создаст новые при необходимости, но случись сделать проверку этих ключей перед запуском на предмет изменения/удаления была бы неприятность. Так что смело удалять непарные значения - не очень хороший совет.
Да и кроме LEGACY_ и других префиксов навалом, Джетика ещё создаёт JT_, Касперский KL_.

Dimitr1s

Учту. Не обращал на них внимания. Спасибо за подсказку!

По поводу Enum-ключей: да, я их тоже в обязательном порядке проверял и чистил. Методика следующая: обнаруживаю ключ, относящийся к искомой программе, дальше смотрю в Диспетчере устройств (Non-Plug-and-Play). Если нахожу — удаляю сначала оттуда (если надо, перезагружаюсь), потом лезу обратно в реестр и подчищаю уже хвост в виде Enum-ключа.

В моём случае накладок не было: каждый раз, если я находил ненужный ключ-хвост, то этот ключ либо соответствовал живому драйверу (а именно: сам ключ содержал подветку 0000, к нему была пара в Services, а сам драйвер присутствовал в Диспетчере), либо это был мёртвый хвост (сам ключ не содержал никаких подветок, пары в Services к нему не было, и в Диспетчере устройств соответствующий драйвер отсутствовал). Соответственно, если я натыкался на живой драйвер (в частности, в Джетике 2.1.0.9 оставался некий Jetico firewall filter или как-то так, не помню точное название), то я сначала грохал его в Диспетчере устройств, перезагружался, после чего в Services этого драйвера больше не было, подветки 0000 у Enum-ключа тоже, так что оставалось только удалить теперь уже пустой Enum-ключ.

Dimitr1s

Цитата:

Если включить только на драйвера Джетико, то с большой вероятностью да, только BSOD.

Хорошо, тогда попробую.


Цитата:

Смутило это:
Цитата: Прогнал ещё и через Revo

CaptainFlint
Попробуйте последний раз такой вариант:
Удалить начисто Касперского, пройтись ремувером о них, пару раз перегрузиться.
Установить Jetico 2.1.0.8, после того как инсталлятор отработает не перегружайтесь, а закиньте перед перезагрузкой в \Jetico Personal Firewall\Config\ свой старый файл конфигурации. Только заранее пересчитайте хэш новых jpfsrv.exe и jpf.exe и исправьте в jpfconfig.xml:
<application value="C:\Program Files\Jetico\Jetico Personal Firewall\jpf.exe" />
<hash value="новый хэш" />
и
<application value="C:\Program Files\Jetico\Jetico Personal Firewall\jpfsrv.exe" />
<hash value="новый хэш" />
и только после перегрузите.
Повторить пару раз.
И проверьте, навсякий, несколько общих значений (ХР SP3), которые jpfsrv.exe считывает при старте: [more=вот]
[HKEY_CLASSES_ROOT\TypeLib\{4B6FB6D7-AB37-4168-9787-B019A28B390A}\1.0\0\win32]
@="C:\\Program Files\\Jetico\\Jetico Personal Firewall\\jpfsrv.exe"

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon]
"ParseAutoexec"="1"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions]
"ProductType"="WinNT"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM]
"Logging"="1"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3]
"REGDBVersion"=hex:0f,00,00,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3]
"Com+Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"everyoneincludesanonymous"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"CriticalSectionTimeout"=dword:00278d00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
"TSUserEnabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
"TSAppCompat"=dword:00000000[/more]

Dimitr1s
Проделал всё это — не помогло. Значения реестра проверил — совпадают, кроме COM3 (который сбросился после удаления соответствующей ветки, когда я пытался переустанавливать COM+). Попробовал вернуть эти значения, толку нет.

Victor_VG
Попробовал выставить запуск сервиса от имени админа, результат не изменился.

Добавлено:
Dimitr1s
Попробовал натравить Driver Verifier. Поставил все драйвера от Jetico на слежение, перезагрузился (как потребовал Verifier), падений нет. Позапускал несколько раз сервис вручную — результат тот же.

CaptainFlint
[more=нашел у себя инфу о похожем глюке]
в свое время игрался с Jetico переустанавливая разные версии (пытался выбрать наименее глючный вариант) и попал в ситуацию похожую с твоей

Цитата:

После переустановки JPF - нет связи с сервером...

решилось подменой jpfconfig.xml на один из файлов из бакупа
fix-server.error.rar
причем ситуацию удалось повторить несколько раз
[/more]

Последняя однёрка 1.0.1.61 работает на х64-ХР виндах? На х86/х64 7-ке?

CaptainFlint
Тогда остаётся писать Nail'у (на support@jetico.com).

Tim72
Вообще jpfconfig.xml, теоретически не должен влиять на запуск сервера, т.к. он стартует до применения правил. А запустить с политикой по умолчанию "Allow all", можно таким образом:
При выключенной Jetico, перенести в jpfconfig.xml атрибут default="1" из "Optimal protection" в "Allow all". То есть было:

Код: <policy name=""Allow all">
...
<policy name="Optimal Protection" default="1">

Dimitr1s

Цитата:

Тогда остаётся писать Nail'у

Я на их форум писал, мне Tommy пообещал, что попросит его глянуть. Если долго не будет реакции, попробую написать по мылу.

CaptainFlint
Если своими силами не удаётся исправить, наверное, лучше сразу ему - отвечает очень быстро, плюс отлично владеет русским. [more=off:]Даже закралось подозрение, что если писать по русски отвечает всегда и почти сразу, м.б. ностальгия [/more]