Dimitr1s
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
tahomavlz
Цитата:| в том, что все равно придется разрешать его любому работающему процессу, чтобы у всех остальных не заблокировалась сеть. |
Ты забыл добавить самое важное: любому доверенному процессу, т.е. такому в котором ты уверен, что он не содержит вредоносный код.
Цитата:| и в том, что я ничего не теряю, если разрешу его всем. |
Ну если следовать такой философии, то ничего не потеряешь если отключить проактивку вообще, если нет желания хоть немного разобраться, толку от неё ноль.
Цитата:| ведь есть же process attack. возможно indirect access умеет отлавливать то что не умеет process attack. но если так, то это бред, т.к. сама атака на процесс будет пропущена, и вдруг внезапно всплывет при попытке доступа к сети. |
По той ссылке что ты привёл, хоть кратко и расплывчато ответ про различие indirect access и process attack был дан. Попробую объяснить проще своими словами: Возьмём для примера работу приложений через SERVICES.EXE, что бы система нормально работала для SERVICES.EXE приходится разрешать почти все виды доступа. Теперь запустим процесс не имеющий в коде вызовов сетевых функций (соответственно передать с твоей машины он ничего не сможет), но работающий с помощью/через SERVICES.EXE, процесс чистый ты соответственно создаёшь для SERVICES.EXE разрешающие правила с некоторыми (не столь важно какими конкретно) видами доступа. Далее запускается процесс вредоносный имеющий в коде вызов сетевых функций (с целью передать собранную у тебя инфу) и написан он так, что бы отработать помощью/через SERVICES.EXE, по совпадению через те же некоторые функции которые мы разрешили в предыдущем случае для легитимного процесса. Далее произойдёт что: вредоносный процесс должен бы отработать через уже разрешённые для исполнения функции в process attack для SERVICES.EXE, но так как в коде есть вызов сетевых функций сработает indirect access и ты получишь запрос. Как говорится почувствуй разницу. Это я привёл просто как пример, на самом деле всё немного сложнее, но смысл надеюсь ясен.
Цитата:| process attack.. странный. такое ощущение что он просто фолсит. например, если ему верить то у меня почти все процессы требуют повышенные привилегии и управление сервисами. |
Абсолютно вменяемый. На самом деле так оно и есть.
Цитата:| application checksum. на данный момент неюзабелен. каким образом я должен определить, разрешить или запретить "такой то процесс с таким то хешем"? на офф форуме было толковое предложение... ...но кажется его проигнорили |
Ну и слава богу, что проигнорили. Во первых: эта таблица в первую очередь информативная, по большому счёту тут ни запрещать, ни разрешать ничего не надо. А свою задачу подсчёта хэша выполняет исправно. Во вторых: по поводу предложения авто-обновления хэша уже существующего, ты вдумайся как следует каким образом можно доверять этой процедуре, если сейчас за пять минут "школьник" может подправить ехе.шник и подменить любые данные. Ты скорее всего придёшь к выводу, что доверять можно только программе имеющей цифровую подпись и надо иметь базу данных с оными, регулярно пополняемую и с организованным доступом к ней. Если интересно посмотри как это организовано в КИС и почитай отзывы. Лично мне подобного в Джетике ни как не хотелось бы, да и толку по большому от этого не много (в основном если используешь софт с ЦП, но тогда, опять же, риск подцепить что то и так ничтожен).
|
Правда, дяди в Редмонде в последние дни могли всё поменять для облегчения запуска игрушек и увеличения прибыли за счёт открытия новых платно-затыкаемых дыр,
и рожицы стали зелёными!! 
Что-то я не пойму, в чём принципиальное отличие, если Джетика кричала бы о новой программе или об изменённой программе… Что так, что эдак невнимательный пользователь нажмёт "да", а внимательный будет думать, с чего файл поменялся. Только в первом случае таблица захламляется кучей записей, а во втором — нет.