Ru-Board.club
← Вернуться в раздел «Программы»

» Jetico Personal Firewall

Автор: GQ
Дата сообщения: 12.09.2006 11:23

Цитата:
а на транспортном уровне входящие соединения никто не разрешал, а jetico лепит реджекты на апликатион уровень, а т.к. приложение неизвестно вот он и ставит системс... Смешно просто

Если у тебя кто-то (в данном случае ядро (а даже не сервис)) слушает порт 445, то срабатывает правило с вердиктом Accept на пакеты прошедшие Statefull inspection из таблицы IP. Это и есть связь пакетного фильтра с фильтрацией на уровне приложений.
Автор: greenfox
Дата сообщения: 12.09.2006 11:39
GQ

Цитата:
Если у тебя кто-то (в данном случае ядро (а даже не сервис)) слушает порт 445
у меня ничего нет на 445 - служба "сервер" и та остановлена, соотв шаринга нет. Куда он там пытается законектиться на 445? Получается в пустоту - т.е. идёт обычный коннект на 445 порт который по логике ipfw должен быть отброшен (при чём именно на tcp\ip уровне - при чём тут app с этим system?) ибо правилами коннект этот не разрешён. Но тут я смотрю как то разрабы иначе замутили логику (т.е. она не ipfw)?
Цитата:
равило Accept пакеты прошедшие Statefull inspection из таблицы IP на него срабатывает. Это и есть связь пакетного фильтра с фильтрацией на уровне приложений.
можно подробней плиз, а то справка 0-я прямо скажем. И так приплывает пакет на 445 порт (tcp, 445 port, icoming connection) что куда там смотрит jetico? Наск я понял он начинает смотреть таблицы с уровня app?
Автор: GQ
Дата сообщения: 12.09.2006 11:47

Цитата:
у меня ничего нет на 445 - служба "сервер" и та остановлена, соотв шаринга нет. Куда он там пытается законектиться на 445?

Прочти еще раз то, что я написал. Не в пустоту, а непосредственно к ядру. За вопросами, нахрена так делать, что ядро занимается такими вещами - спрашивай майкрософт.


Цитата:
И так приплывает пакет на 445 порт (tcp, 445 port, icoming connection) что куда там смотрит jetico? Наск я понял он начинает смотреть таблицы с уровня app?

Он обрабатывает его по правилам. доходит до правила Statefull inspection. Смотрит в системные таблицы винды, видит, что этот сокет открыт и слушается, и делает резолюцию accept. Это не связь между таблицами (может я где не так выразился выше, перечитывать неохота), а
Цитата:
связь пакетного фильтра с фильтрацией на уровне приложений.


PS Все вышесказанное - мои личные домыслы. =\
Автор: greenfox
Дата сообщения: 12.09.2006 12:11
GQ

Цитата:
Прочти еще раз то, что я написал. Не в пустоту, а непосредственно к ядру. За вопросами, нахрена так делать, что ядро занимается такими вещами - спрашивай майкрософт.
Да какая разница куда он там приходит и как винда обрабатывает на уровне кода входящие пакеты? Смысл в том что у меня на 445 порту нет ничего. Т.е. по лигеке даже в отсутсвтии файера этот пакет (входящий коннект) должен быть отброшен даже самой виндой ввиду того что bind на 445 сокет в системе нету. В его присутствии он его сам должен отбросить - ибо на ip уровне такое не разрешено правилами. Т.е. ещё раз, по логике ipfw перед тем как пакет вообще дойдёт до app уровня и ОС будет думать какому приложению и какими ядерными модулями его передавать, этот пакет будет отброшен самим файером ввиду отсутствия явно заданного правила для его прохождения.
Теперь, в эксперементальных целях, предположим что на 445 порту что-то висит, например стандарт. виндовая служба. Итак, судя по вашим словам (давайте вместе разбираться) пакет начнёт прохождение по таблицам jetico. Судя по справке очерёдность будет именно такой как они идут в root таблице - т.е.
App Table -> System ip table -> Protocol Table -> Process attak table
Итак наш входящий коннект от юного хакера прёт на 445 порт и файер начинает искать соответствия в таблице app? А какие собственно он там соответствия может найти? Разрешено ли System принимать пакеты с заданными параметрами (адреса, порты и т.д.) на 445 порт? Тогда логично предположить что Sysytem это вообще абстрактное понятие характеризующее Ос в целом? Или в этом месте он смотрит ещё куда-то по мимо App Table?
Далее он по идее, если нет на уровне приложений accept incoming 445 tcp from any any (например) должен смотреть следующие таблицы - System ip table и Protocol Table, так? Тогда вопрос зачем их сейчас вообще смотреть бо даже если там прописано разрешение, на app уровне соотв всё равно нет. Или я чего то не так логику понимаю?

ps про этот Stateful TCP Inspection где-н вообще расписано? Ну там на офф.сайте хотя бы?
Автор: GQ
Дата сообщения: 12.09.2006 12:31

Цитата:
ps про этот Stateful TCP Inspection где-н вообще расписано? Ну там на офф.сайте хотя бы?

не знаю.


Цитата:
Судя по справке очерёдность будет именно такой как они идут в root таблице - т.е.
App Table -> System ip table -> Protocol Table -> Process attak table

Не знаю, кто врет, может и справка, но на деле обработка входящего пакета идет так:

По таблица типа Network и IP из корневой по порядку, пока не найдет вердикт.
Затем
По таблицам типа Application из корневой по порядку, пока не найдет вердикт.


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


Цитата:

Цитата: Прочти еще раз то, что я написал. Не в пустоту, а непосредственно к ядру. За вопросами, нахрена так делать, что ядро занимается такими вещами - спрашивай майкрософт.

Да какая разница куда он там приходит и как винда обрабатывает на уровне кода входящие пакеты?
Автор: greenfox
Дата сообщения: 12.09.2006 12:49
GQ

Цитата:
Не знаю, кто врет, может и справка, но на деле обработка входящего пакета идет так:

По таблица типа Network и IP из корневой по порядку, пока не найдет вердикт.
Затем
По таблицам типа Application из корневой по порядку, пока не найдет вердикт.
в справке сказано чётко:
Цитата:
Entry point for rule processing is the root table of the active Security policy. See Configuration explorer chapter for more information on Security policy navigating.
Jetico Personal Firewall picks rules from current table in series and tests network event parameters against rule condition.
Перевод примерно такой
Цитата:
Точкой для начала обработки правил является корневая таблица активной политики безопасности. Jetico Personal Firewall последовательно выбирает правила из текущей таблицы и сравнивает параметры сетевого события с условием правила. Обработка таблицы продолжается до тех пор, пока не произойдет одно из следующих событий
Т.е. иными словами начало обработки идёт именно с App Table. Откуда вы узнали что сначало идёт ip table? Откуда инфа? принципиальный момент...


Цитата:
Разница такая, что Stateful inspection использует виндовые механизмы для того, чтобы определить пропускать ли этот пакет или нет, в частности порпускает, если этот пакет кто-то готов принять.
это бы имело смысл если бы обработка правил была бы с нижележащего уровня и по возрастающей, тогда да, jetico могбы просмотреть на уровне tcp\udp сист. таблицу сокетов и определить, есть ли смысл вообще фильтроваь этот пакет или его можно сразу отбросить т.к. его всё равно никто не ждёт. Однако (см.выше) jetico начинает обработку правил с уровня приложений. Об этом так же свидетельствует и присловутый System в таблице App Table ибо если бы jetico начинал обработку с ip-tcp\udp таблиц то на этом бы уровне и задавал бы вопрос пользователю не хочет ли он разрешить коннект, и соотв-но на этом бы уровне и прописывал правила ( разрешении коннекта на такой то порт). А в App Table просто бы потом дублировал правило уже с указанием того демона (приложения) которому разрешено принимать на прикладном уровне эти пакеты. Однако jetico лепит всё на уровне App Table
"Однако здравствуйте"(с)...

Добавлено:
ёпть! Он из лана (которую в визарде пишешь) позволяет коннекты на твою машину на сетевом уровне беспрепятственно! Нет, понятно что ланона лан -но вот так открыть машину на вход и не предупредить даже.... мда, походу придётся дать отказ данному продукту второй раз.
Автор: GQ
Дата сообщения: 12.09.2006 13:54
greenfox
утомил, честное слово...

Цитата:
в справке сказано чётко:

меня не интересует что написано в справке, я тебе говорю, как оно есть на самом деле.


Цитата:
то на этом бы уровне и задавал бы вопрос пользователю не хочет ли он разрешить коннект, и соотв-но на этом бы уровне и прописывал правила ( разрешении коннекта на такой то порт). А в App Table просто бы потом дублировал правило уже с указанием того демона (приложения) которому разрешено принимать на прикладном уровне эти пакеты.

он не будет спрашивать в пакетном фильтре!!! патамушта стэйтфул инспекшн! Ну что ты такой непонятливый!!


Цитата:
Он из лана (которую в визарде пишешь) позволяет коннекты на твою машину на сетевом уровне беспрепятственно!

Какой лан? какой визард? какой нахрен сетевой уровень? Ты свою локалку в трастед зоун внес? Тогда сам себе злобный буратино.
Автор: greenfox
Дата сообщения: 12.09.2006 14:02
GQ

Цитата:
утомил, честное слово
ну звиняй, надеюсь статью "по принуждению" шить не будешь
Цитата:
меня не интересует что написано в справке, я тебе говорю, как оно есть на самом деле
так я и спрашиваю как ты это определил? Дебагером смотрел что ли? Просто интересно...
Цитата:
он не будет спрашивать в пакетном фильтре!!! патамушта стэйтфул инспекшн! Ну что ты такой непонятливый!!
не, непонятливый. Т.е. ты хочешь сказать, что этот твой "инспекш" типа делает обрезание? - вместо того что бы добавлять соотв правила как на сетевой так и на прикладной уровень он добавляет их только на прикладной с соотв привязкой (по каким то внутренним параметрам) к сетевому уровню?
Цитата:
Ты свою локалку в трастед зоун внес? Тогда сам себе злобный буратино.
дык это, сколько живу, сколь раз в разных файерах в трастед зон свою лан вносил - ни разу файер не позволял себе такую вольность как не блокировать входяшие коннекты Ужась.
Автор: GQ
Дата сообщения: 12.09.2006 14:32
greenfox

Цитата:
ни разу файер не позволял себе такую вольность как не блокировать входяшие коннекты

Это ПОЛНОСТЬЮ ДОВЕРЕННАЯ ЗОНА. РАЗРЕШЕНО ВСЁ! и это написано всюду.


Цитата:
так я и спрашиваю как ты это определил? Дебагером смотрел что ли? Просто интересно...

Достаточно большое количество экспериментов + *скромно* очень хорошие знания сетевых технологий + логика, которая видимо работает по схожим с логикой разработчиков принципам.
И очень много возни с джетикой пока не снизошла нирвана.


Цитата:
не, непонятливый. Т.е. ты хочешь сказать, что этот твой "инспекш" типа делает обрезание? - вместо того что бы добавлять соотв правила как на сетевой так и на прикладной уровень он добавляет их только на прикладной с соотв привязкой (по каким то внутренним параметрам) к сетевому уровню?

Значит алгоритм на псевдоформальном языке.

Пришел пакет

PF:
для каждой таблицы типа нетворк или IP в корневой таблице
{
для каждого правила из таблицы
{
если выполняются все условия правила, то РЕЗУЛЬТАТ:=вердикт правила;
goto AFTER_PF;
}
}
РЕЗУЛЬТАТ:=???(никогда не интересовался какой у джетики вердикт по-умолчанию)
AFTER_PF:
если РЕЗУЛЬТАТ==REJECT отбросить пакет и выйти из обработчика
AF:
для каждой таблицы типа application в корневой таблице
{
для каждого правила из таблицы
{
если выполняются все условия правила, то РЕЗУЛЬТАТ:=вердикт правила;
goto AFTER_AF;
}
}
РЕЗУЛЬТАТ:=???(никогда не интересовался какой у джетики вердикт по-умолчанию)
AFTER_AF:
если РЕЗУЛЬТАТ==REJECT отбросить пакет и выйти из обработчика
передать пакет дальше в стек винды и выйти из обработчика



В частности, среди правил в таблице пакетного фильтра есть правило if(ip stateful inspection==true) then accept; которое означает, что если пакет ожидается виндой (то есть открыт слушающий сокет или пакет направляется внутренним сущностям (ядру) винды ) и имеет правильную структуру/чексам/флаги то принять этот пакет.

Подробнее писать не буду. Надоело.
Автор: VitRom
Дата сообщения: 12.09.2006 14:34

Цитата:
Т.е. иными словами начало обработки идёт именно с App Table.
Тогда уж для точности формулировки уточнение: если порядок таблиц в Root не изменён.
Т.е. если перетащить в самый верх IP-Table - то и будет проверяться сначала по IP и т.д.

ЗЫ. Инфу эту подтверждают и сами разрабы; я с ними как-то долго переписывался по поводу левых алармов...
Автор: GQ
Дата сообщения: 12.09.2006 14:46
VitRom
Обработка исходящих пакетов - да.
Вначале все аппликейшн, затем все нетворк.
Обработка входящих - нет. если не веришь, воткни первым же правилом в таблицу нетворк reject и убедись сам.

Добавлено:

Цитата:
Т.е. если перетащить в самый верх IP-Table - то и будет проверяться сначала по IP и т.д.

Это не правда. можешь сам проверить, создав правила с логированием в начале каждой таблицы и посмотрев логи.
Автор: greenfox
Дата сообщения: 12.09.2006 15:28
GQ

Цитата:
Достаточно большое количество экспериментов + *скромно* очень хорошие знания сетевых технологий + логика, которая видимо работает по схожим с логикой разработчиков принципам.
И очень много возни с джетикой пока не снизошла нирвана.
нет, ну если вы утверждаете что пакеты обрабатываются как не крути (при вход) именно с ip таблиц это конечно всё меняет\объясняет. Но неужто разрабы написали в справке откровенную ложь?
Автор: VitRom
Дата сообщения: 12.09.2006 15:52

Цитата:
Обработка входящих - нет. если не веришь...
Не верю. Или туплю в чём-то.

Открыл Root и перетащил на самый верх IP-Table.
Открыл IP-Table.
В ней сдублировал на самый верх последний режект (Block All not-processed) и исправил его с any/any/... на any/incoming/..., коммент оставил.
Открыл AppTable.
В ней сделал 2 режекта на receive datagrams и inbound connect.

Включил все 3 - в логе только 1-й (Block All not-processed)
Автор: greenfox
Дата сообщения: 12.09.2006 16:21
VitRom
а если не перетаскивать в root таблице наверх ip-table и повторить эксперемент то что будет?

2all
так и не понял что означает System - для системных процессов ОС (lsass, svhost, userinit, rundll32 и т.д.) всё выдаётся ка положено - имя процесса и т.д. А с систем что то непонятное...
Автор: GQ
Дата сообщения: 12.09.2006 17:05
greenfox
Возможно они написали не совсем внятно. =\ Документация там сильно хромает.

На самом деле там все немножко хитрее, там 2 разных фильтра, которые вызываются по разным событиям - пакетный фильтр при приеме/отправке сообщения.

фильтр приложений срабатывает при любом взаимодействии с сокетами - открытие, коннект, чтение, запись.

И на самом деле есть еще третий фильтр, который использует таблицы типа процесс аттак.

Я так понимаю, что вопрос, который был в оригинальном сообщении до исправления наконец-таки снялся? ура.

Еще раз: разработчики винды сделали несколько странных вещей. например рассылка широковещательных запросов НетБиос, которые используются для выяснения имен и договоренности насчет браузера (имеется в виду браузер рабочей группы в нетбиос) идет от имени System, т.е. от модуля стека TCP/IP, от ядра, а нет от службы.

VitRom
Если не перетащишь - увиддишь то же самое.
Короче, поставь в каждой таблице логирование в начале и в конце и посмотри на последовательность
Автор: greenfox
Дата сообщения: 12.09.2006 17:14
GQ

Цитата:
Я так понимаю, что вопрос, который был в оригинальном сообщении до исправления наконец-таки снялся? ура.
ну если принять во внимание что документация откровенно противоречит вашей точке зрения - то да. :/ Спасибо так сказать что нашли время её высказать, пока что другого объяснения увы нет.
Цитата:
Еще раз: разработчики винды сделали несколько странных вещей. например рассылка широковещательных запросов НетБиос, которые используются для выяснения имен и договоренности насчет браузера (имеется в виду браузер рабочей группы в нетбиос) идет от имени System, т.е. от модуля стека TCP/IP, от ядра, а нет от службы.
хм, да... вообще то у меня в логах этот систем в основном лезет наружу по 137-139 и 445 портам, странно конечно...

ps интересно как они собираются продавать 2-ю версию с такой документацией и неразберихой :/
Автор: kesic
Дата сообщения: 12.09.2006 17:40
greenfox
А ты запусти netstat -ano и посмотришь, какие порты у тебя открыты.
Автор: greenfox
Дата сообщения: 12.09.2006 18:58
kesic
спасибо, но я и сам "не первый раз замужем"(с)
Автор: kesic
Дата сообщения: 12.09.2006 22:59
greenfox
Да нет проблем.
Кстати, по поводу System. Это системный процесс, на котором "висят" драйвера устройств, со всеми вытикающими из этого последствиями
Автор: VitRom
Дата сообщения: 13.09.2006 15:25
greenfox
Цитата:
а если не перетаскивать в root таблице наверх ip-table и повторить эксперемент то что будет?
Будет "заводской конфиг", первым сработает AppTable.

ОК, повторил. Результат в логе:
IP-блоки для входящих локальных бродкастов и среди них блоки программ
Автор: GQ
Дата сообщения: 13.09.2006 15:25

Цитата:
вообще то у меня в логах этот систем в основном лезет наружу по 137-139 и 445 портам

НетБиот, РПЦ =\


Цитата:
ps интересно как они собираются продавать 2-ю версию с такой документацией и неразберихой :/

Ну может во второй версии получше сделана документация и этот вопрос более-менее решен.

Добавлено:

Цитата:
Будет "заводской конфиг", первым сработает AppTable.

Для входящих первым сработает блок в IP.


Цитата:
IP-блоки для входящих локальных бродкастов и среди них блоки программ

Блоеи из аппликейшт тэйбл на входящие пакеты? не верю.

Добавлено:
Новости о второй версии:
13-September-2006 version 2.0.0.9 beta released. Changes:

* System crash on rules with empty groups (appeared in v 2.0.0.8) fixed.
* Rule from log creation function fixed.
Автор: VitRom
Дата сообщения: 13.09.2006 15:44
GQ

Цитата:
Для входящих первым сработает блок в IP.
Думается, так и должно быть - входящий-то пакет идёт на порт, а не конкретной апп.

Цитата:
Блоки из аппликейшт тэйбл на входящие пакеты? не верю.
Ну, может, я в чём и поторопился и не проверил всё точно.
Хотя в этих блоках ничего удивительного - был запущен ВинРоутский Админ, подключенный к другой машине. ВинРоут отдаёт лог в админ-клиента по УДП. При любой команде (очистить, показать конфиг и т.п.) клиент задумывался, после таймаута (т.е. пакеты с командой уходили) говорил, что коннект потерян, а в логе появлялась строка именно о нём (<path>\wradmin.exe)
Автор: greenfox
Дата сообщения: 14.09.2006 00:02
вопрос интересный возник:
по справке этот самый "access to network" означает всего лишь что приложение пытается получить доступ к сетевым библиотекам. Однако тот же ping работает с сетью свободно только при одном правиле "access to network" - т.е. пакеты на уровне ip приложение может отсылать имея всего ли данный вид доступа?
Автор: XenoZ
Дата сообщения: 14.09.2006 13:06
2greenfox
Посмотрел у себя.
При пинге в Trusted Zone все проходит (правило accept all в таблице System Trusted Zone)
При пинге в Blocked Zone все режется (правило reject all в таблице System Blocked Zone)
На все остальные адреса пинг работает в таблице System Internet Zone по правилам:
accept Allow ICMP Ping info ICMP    incoming packet...
accept Allow ICMP Ping info ICMP    outgoing packet...
accept Allow incoming ICMP Unreachable info ICMP incoming packet...
accept Allow incoming ICMP Time Exceeded    info ICMP incoming packet...

Не вижу проблемы .
Автор: greenfox
Дата сообщения: 14.09.2006 13:38
XenoZ
мда, спасибо что поправили, я и забыл что там правила прописаны...
Автор: XenoZ
Дата сообщения: 16.09.2006 01:10
13-September-2006 version 2.0.0.9 beta released. Changes:
System crash on rules with empty groups (appeared in v 2.0.0.8) fixed.
Rule from log creation function fixed.
Автор: DOE_JOHN
Дата сообщения: 16.09.2006 18:02
Eliza
Остается только восхищаться настойчивостью в изучении такой сложной в настройке для простого пользователя программы как Jetico.

ArtLonger
То что Jetico не стартует как сервис у большинства компенсируется автовходом пользователя. Так что период незащищенного состояния стремится к минимуму.
Автор: kesic
Дата сообщения: 16.09.2006 19:58
А есть ли модуль для Jetico который бы выводил в трей инфо об атаках?
Автор: ILYA83
Дата сообщения: 16.09.2006 23:00
По тесту http://www.hackerwatch.org/probe/ открыт порт HTTP 80.Как прикрыть ?
Автор: ArtLonger
Дата сообщения: 17.09.2006 13:31
DOE_JOHN

Цитата:
То что Jetico не стартует как сервис у большинства компенсируется автовходом пользователя. Так что период незащищенного состояния стремится к минимуму.

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

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687

Предыдущая тема: pcInternet Patrol


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.