Я всерьёз надеюсь, что снял доводы типа "да это же раз плюнуть". Они в таких беседах очень часто вылезают.
Предлагаю самостоятельно реализовать работающий макет и посрамить этих "крутых программеров", которые только и умеют, что вкручивать о сложностях разработки.
Вы всерьез полагаете, что кому-то нечем заняться?

Работа с файлом Hosts (практически крик души)
#121
Отправлено 14 Январь 2013 - 15:51
#122
Отправлено 14 Январь 2013 - 16:34
Имею мнение... Модифицированный файл HOSTS за файл по-умолчанию брать нельзя, потому что невозможно гарантировать отсутствие в нём заражения, что сводит на нет работу антируткита с этим файлом.
Почему?
Может, все же мне видней, заражен он или нет? Если я решаю, что мой файл чист, то почему АВ считает, что он главнее на моей машине?
Потому что установленный по-умолчанию заражённый файл HOSTS средствами антивируса будет считаться не каким иначе, как именно чистым!
Что сводит на нет использование превентивной защиты и фонового сканирования в рамках этого файла.
Более того, требует реализации контроля за файлом со стороны других компонентов защиты, иначе и вылечить заражение будет невозможно средствами антивируса.
О запросах со стороны svchost, defrag на HOSTS знаю и да - неудобно. И нужно поправить.
Тема вообще то о проблемах с хост файлом, как части превентивки.
Если в упор не видите проблем, зачем писать то здесь? Создайте тему "Как все мазево сделано в превентивке" и хвалите там ее вслать.
Работу превентивной защиты не хвалил и не не собирался. Я высказался о том, что её работа с конкретно файлом HOSTS вполне адекватна. И как иначе в текущей реализации может быть мне действительно непонятно. Потому что предложенные варианты как я описал в предыдущем сообщении и в этом не совсем безопасны. Проблемы есть и я их не отрицаю. Сам денвером пользуюсь. И defrag с svchost баламутят воду.
*Проблемы с юзабилити, да.
Сообщение было изменено Badwater: 14 Январь 2013 - 16:35
#123
Отправлено 14 Январь 2013 - 17:09
Я всерьёз надеюсь, что снял доводы типа "да это же раз плюнуть". Они в таких беседах очень часто вылезают.
Предлагаю самостоятельно реализовать работающий макет и посрамить этих "крутых программеров", которые только и умеют, что вкручивать о сложностях разработки.
Вы всерьез полагаете, что кому-то нечем заняться?![]()
Какие доводы? Обсуждали еще тогда - было сказано, что это можно сделать, не несложно сделать, но это сделано не будет.
Имею мнение... Модифицированный файл HOSTS за файл по-умолчанию брать нельзя, потому что невозможно гарантировать отсутствие в нём заражения, что сводит на нет работу антируткита с этим файлом.
>>Почему?
Может, все же мне видней, заражен он или нет? Если я решаю, что мой файл чист, то почему АВ считает, что он главнее на моей машине?
Потому что установленный по-умолчанию заражённый файл HOSTS средствами антивируса будет считаться не каким иначе, как именно чистым!
Что сводит на нет использование превентивной защиты и фонового сканирования в рамках этого файла.
Более того, требует реализации контроля за файлом со стороны других компонентов защиты, иначе и вылечить заражение будет невозможно средствами антивируса.
Почему зараженный? Откуда зараженный? Я его вижу - ну нету там заражения! И при чем тут превентивная защита? Какое отношение к этому имеет фоновое сканирование? О чем это Вы вообще?
Еще раз: сейчас так: есть эталонный файл hosts, с которым сравнивается текущий. Любое изменение текущего файла вызывает приведение его к эталону. Что предлагалось: показать пользователю текущий файл. Если пользователь сказал, что файл в порядке, то считать этот файл новым эталоном. С ним - и только с ним - проверять изменения. Всё! Ну какая разница антивирусу, с чем сравнивать - с эталонным виндовым или с эталонным пользовательским.
Сообщение было изменено Borka: 14 Январь 2013 - 17:12
Борис А. Чертенко aka Borka.
#124
Отправлено 14 Январь 2013 - 17:11
Ну капец какой-то... Может, хоть кто-нибудь починит отвалившееся квотирование?
Борис А. Чертенко aka Borka.
#125
Отправлено 14 Январь 2013 - 17:32
С чем сравнивать разницы нет. Но это надо делать, а делать не хотят.
Не хотят либо по причине небольшой востребованности (мало кому вообще упал этот hosts), либо по причине политики партии (дополнительный вопрос, на который блондинке сложно ответить).
По мне так и текущий вариант нормальный. Хотя отключение запрета в проактивке могло бы автоматом отключать детект на файл. Всего-то еще одно системное исключение добавить/удалить. Но это уж модульность мешает видать, которая и есть наша всё
#126
Отправлено 14 Январь 2013 - 21:31
С чем сравнивать разницы нет. Но это надо делать, а делать не хотят.
Не хотят либо по причине небольшой востребованности (мало кому вообще упал этот hosts), либо по причине политики партии (дополнительный вопрос, на который блондинке сложно ответить).
По мне так и текущий вариант нормальный. Хотя отключение запрета в проактивке могло бы автоматом отключать детект на файл. Всего-то еще одно системное исключение добавить/удалить. Но это уж модульность мешает видать, которая и есть наша всё
Люди хотят и изменения сами вносить туда и защищать Доктором его.
#127
Отправлено 14 Январь 2013 - 21:47
Почему зараженный? Откуда зараженный? Я его вижу - ну нету там заражения! И при чем тут превентивная защита? Какое отношение к этому имеет фоновое сканирование? О чем это Вы вообще?
Установлен Dr.Web. Файл HOSTS может быть заражён откуда угодно и как угодно при отключенной проверке превентивной защиты этого файла или конкретно явном разрешении на модификацию файла со стороны якобы доверенного приложения. Фоновое сканирование проверяет файл не сразу после изменения. Где вы видите отсутствие заражения я знать не могу, если вы говорите о диалоге, описанном вами ниже:
Еще раз: сейчас так: есть эталонный файл hosts, с которым сравнивается текущий. Любое изменение текущего файла вызывает приведение его к эталону. Что предлагалось: показать пользователю текущий файл. Если пользователь сказал, что файл в порядке, то считать этот файл новым эталоном. С ним - и только с ним - проверять изменения. Всё! Ну какая разница антивирусу, с чем сравнивать - с эталонным виндовым или с эталонным пользовательским.
Разница в том, что пользователь может ошибиться и установить пользовательским эталонным файлом заражённый. Да, ССЗБ. Но ошибиться может любой человек. И тогда заражённый файл будет считаться чистым файлом. Ещё раз подчёркиваю - чистым. И прощай защита, ибо фоновая проверка при следующем запросе на изменение файла на ответ "Не разрешать" будет приводить файл к эталонному - заражённому, и возможно при ответе "Разрешить". При том о своей ошибке возможно узнать лишь посмотрев этот файл самостоятельно, либо при следующем запросе фоновой проверки на изменение файла. Тот же сканер читает эталонный - заражённый и считает чистым. Всё это недопустимо. Поэтому пользовательский файл нельзя считать эталоном. Вот по этому я и считаю более логичным текущее поведение и например внесение файла HOSTS в исключение.
Перечитал тему, прикинул, как оцените алгоритм, в принципе описывающий те же яйца:
по-умолчанию HOSTS чистый и сравнение идёт с ним и только с ним
установлено изменение файла HOSTS "по запросу" или "разрешено" в настройках превентивной защиты
программа пытается изменить файл
превентивная защита выдаёт запрос на разрешение или запрет доступа (или разрешает автоматически, если установлено в настройках)
если разрешает пользователь вручную, сохраняем хэш файла (хэш и хэш файла только как пример)
дальше фоновая проверка обнаруживает изменения в файле HOSTS по сравнению с чистымвыдаётся запрос, посмотреть, исправить или нет
на ответ исправить файл будет приведён к эталонному файлу - чистому
на ответ нет:
если хэш файла совпадает с хэшем, сгенерированным при разрешении изменения пользователем вручную при запросе превентивной или фоновой проверки, больше не спрашиваем, иначе сохраняем новый хэш, больше не спрашиваем
при запрете на изменения файла в настройках превентивной защиты
если есть сохранённый хэш, то фоновая проверка будет задавать вопрос при изменений файла, иначе нет и будет восстанавливать в чистый
при первоначальной установке также будет восстанавливать в чистый
предусмотреть сброс хэша последнего разрешённой модификации файла и возврат к эталонному файлу из меню
В итоге: при работе фоновой проверки Можно выдавать сообщение о том, что текущий файл HOSTS отличается от чистого и это изменение разрешил сам пользователь, а сканер Может не читать всякие хэши и всегда говорит об обнаружении изменения в файле и при исправлении возвращает именно чистый файл, заведомо не заражённый
При установке антивируса файл HOSTS будет очищен, а старый будет сохранён в карантин, и впредь с настройками по умолчанию в превентивной защите фоновое сканирование будет чистить его каждый раз без предупреждения.
Если нужно работать с изменённым HOSTS, надо изменить настройки в превентивной защите один раз на требуемый уровень и возможно потом вернуться на значения по-умолчанию (запрет на изменение) и возможность возврата к эталонному чистому файлу и отключению запроса на изменение файла со стороны фонового сканирования
#128
Отправлено 14 Январь 2013 - 21:49
А защищается ли превентивкой изменеие расположения хоста в реестре?
#129
Отправлено 14 Январь 2013 - 22:21
А защищается ли превентивкой изменеие расположения хоста в реестре?
Да. Но по своему... Если не ошибаюсь.
Сообщение было изменено SergSG: 14 Январь 2013 - 22:21
#130
Отправлено 14 Январь 2013 - 22:45
поржал
%SystemRoot%\system32\drivers\etc\hosts, его расположение может быть переопределено в ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\DataBasePath, в котором содержится путь к папке.
Превентивка дает его изменять в реестре
А вы тут 15 страниц написали
Сообщение было изменено mrbelyash: 14 Январь 2013 - 22:47
#131
Отправлено 14 Январь 2013 - 23:08
Перечитал тему, прикинул, как оцените алгоритм, в принципе описывающий те же яйца:
по-умолчанию HOSTS чистый и сравнение идёт с ним и только с ним
установлено изменение файла HOSTS "по запросу" или "разрешено" в настройках превентивной защиты
программа пытается изменить файл
превентивная защита выдаёт запрос на разрешение или запрет доступа (или разрешает автоматически, если установлено в настройках)
если разрешает пользователь вручную, сохраняем хэш файла (хэш и хэш файла только как пример)
дальше фоновая проверка обнаруживает изменения в файле HOSTS по сравнению с чистым
выдаётся запрос, посмотреть, исправить или нет
на ответ исправить файл будет приведён к эталонному файлу - чистому
на ответ нет:
если хэш файла совпадает с хэшем, сгенерированным при разрешении изменения пользователем вручную при запросе превентивной или фоновой проверки, больше не спрашиваем, иначе сохраняем новый хэш, больше не спрашиваем
при запрете на изменения файла в настройках превентивной защиты
если есть сохранённый хэш, то фоновая проверка будет задавать вопрос при изменений файла, иначе нет и будет восстанавливать в чистый
при первоначальной установке также будет восстанавливать в чистый
предусмотреть сброс хэша последнего разрешённой модификации файла и возврат к эталонному файлу из меню
В итоге: при работе фоновой проверки Можно выдавать сообщение о том, что текущий файл HOSTS отличается от чистого и это изменение разрешил сам пользователь, а сканер Может не читать всякие хэши и всегда говорит об обнаружении изменения в файле и при исправлении возвращает именно чистый файл, заведомо не заражённый
При установке антивируса файл HOSTS будет очищен, а старый будет сохранён в карантин, и впредь с настройками по умолчанию в превентивной защите фоновое сканирование будет чистить его каждый раз без предупреждения.
Если нужно работать с изменённым HOSTS, надо изменить настройки в превентивной защите один раз на требуемый уровень и возможно потом вернуться на значения по-умолчанию (запрет на изменение) и возможность возврата к эталонному чистому файлу и отключению запроса на изменение файла со стороны фонового сканирования
Не надо изобретать вилосепедоф, все уже придумали. Вот странно почему мой хост не имеет место быть, предан анафеме и стал изгоем?
# Copyright © 1993-1999 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a ‘#’ symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
127.0.0.1 localhost
127.0.0.1 serial.alcohol-soft.com
127.0.0.1 www.alcohol-soft.com
127.0.0.1 images.alcohol-soft.com
127.0.0.1 trial.alcohol-soft.com
127.0.0.1 alcohol-soft.com127.0.0.1 genuine.microsoft.com
127.0.0.1 mpa.one.microsoft.com
127.0.0.1 sls.microsoft.com
Почему так получается что, вполне легитимные изменения не в плане нравственности и закона, а в плане самого содержания и смысла, лишают меня защиты? Мало того что это все надо забивать руками так как к примеру активаторы попросту обломаются , еще надо понять почему не работает и кто постоянно правит hosts и поняв кто правит, понять то, что один компонент защиты по сабжу отпал.
Господа это конечно же пример, сделанный специально для наглядности, но это имеет место быть и в более безобидных формах. Ведь другие же делают для людей и стараются учитывать все интересы, но вот для Badwater у нас есть есть фича, а вот к примеру для меня ее просто нет, хотя цена лицензии так между делом не уменьшилась. Почему не реализовать к примеру режим для тех кому трудно и для тех кому есть куда расти. На ряду с настройками разработчиков прикрутить возможность под настроить что то самому. Например туже не сигнатурную защиту от тех же винлоков к примеру и не ждать каких то баз.
Того же хоста в реестре, пути, файлы паролей, пользовательские директорий браузеров, интернет пейджеров, файловых менеджеров да чего угодно.
Указать кому куда можно, кому куда нельзя, отдельно или по группам которые формирует облако и можно так же группировать самому как угодно и что угодно.
Сообщение было изменено run: 14 Январь 2013 - 23:13
#132
Отправлено 14 Январь 2013 - 23:59
1. Вчера?
2. Здесь и сейчас?
3. На будущей неделе?
4. К лету?
5. В следующей версии?
IMHO, в беседах подобного типа неявно предполагается вариант №2, поэтому и ответ: здесь и сейчас делать не будем.
А если расширить рамки, то думаю, что ответ будет примерно таким: сделаем, когда поймём, что делать надо именно это, а также поймём, как именно это надо делать. Плюс время на разработку.
#133
Отправлено 15 Январь 2013 - 01:07
поржал
%SystemRoot%\system32\drivers\etc\hosts, его расположение может быть переопределено в ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\DataBasePath, в котором содержится путь к папке.
Превентивка дает его изменять в реестре
А вы тут 15 страниц написали
http://forum.drweb.com/index.php?showtopic=312286&p=645449
#134
Отправлено 15 Январь 2013 - 07:57
run, Почему вы всегда рекламируете противопоставляете продыкты ЛК Доктор Веб ? Если бы вы знали сколько у них времени ушло на то, что сейчас есть у них, сколько проб и ошибок они допустили, вероятно не стали бы этого делать.
Доктор Веб за 1 год произвёл революцию в архитектуре АВ. Естественно потребуется время на выработку собственных путей реализации модулей псевдохипса. Слишком долго держались за (хорошую, надёжную) 6-ю версию, вот и по-отстали.. И тем не менее вполне достойный продукт получился. IMHO
Сиюминутное Ригпа бессущностно и ясно.
#135
Отправлено 15 Январь 2013 - 09:11
поржал
%SystemRoot%\system32\drivers\etc\hosts, его расположение может быть переопределено в ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\DataBasePath, в котором содержится путь к папке.
Превентивка дает его изменять в реестре
А вы тут 15 страниц написали
поржал
%SystemRoot%\system32\drivers\etc\hosts, его расположение может быть переопределено в ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\DataBasePath, в котором содержится путь к папке.
Превентивка дает его изменять в реестре
А вы тут 15 страниц написали
Как говорится почуствуйте разницу-защищаю или лечу.
#136
Отправлено 15 Январь 2013 - 09:18
кстати что то не вижу этого лечения простым сканером....может этотолько фоновая лечит
#137
Отправлено 15 Январь 2013 - 09:28
кстати что то не вижу этого лечения простым сканером....может этотолько фоновая лечит
Фоновая проверка лечит по новому пути.... через много часов после.
#138
Отправлено 15 Январь 2013 - 09:38
Боюсь смотреть теперь куреит...кто же там ему поможет
#139
Отправлено 15 Январь 2013 - 11:58
кстати что то не вижу этого лечения простым сканером....может этотолько фоновая лечит
Сканер лечит HOSTS если запускать его с проверкой на руткиты. Если просто запустить проверку файла, то там чисто все будет.
#140
Отправлено 15 Январь 2013 - 12:56
Почему зараженный? Откуда зараженный? Я его вижу - ну нету там заражения! И при чем тут превентивная защита? Какое отношение к этому имеет фоновое сканирование? О чем это Вы вообще?
Установлен Dr.Web. Файл HOSTS может быть заражён откуда угодно и как угодно при отключенной проверке превентивной защиты этого файла или конкретно явном разрешении на модификацию файла со стороны якобы доверенного приложения. Фоновое сканирование проверяет файл не сразу после изменения. Где вы видите отсутствие заражения я знать не могу, если вы говорите о диалоге, описанном вами ниже:
Еще раз: сейчас так: есть эталонный файл hosts, с которым сравнивается текущий. Любое изменение текущего файла вызывает приведение его к эталону. Что предлагалось: показать пользователю текущий файл. Если пользователь сказал, что файл в порядке, то считать этот файл новым эталоном. С ним - и только с ним - проверять изменения. Всё! Ну какая разница антивирусу, с чем сравнивать - с эталонным виндовым или с эталонным пользовательским.
Разница в том, что пользователь может ошибиться и установить пользовательским эталонным файлом заражённый. Да, ССЗБ. Но ошибиться может любой человек. И тогда заражённый файл будет считаться чистым файлом. Ещё раз подчёркиваю - чистым. И прощай защита, ибо фоновая проверка при следующем запросе на изменение файла на ответ "Не разрешать" будет приводить файл к эталонному - заражённому, и возможно при ответе "Разрешить". При том о своей ошибке возможно узнать лишь посмотрев этот файл самостоятельно, либо при следующем запросе фоновой проверки на изменение файла. Тот же сканер читает эталонный - заражённый и считает чистым. Всё это недопустимо. Поэтому пользовательский файл нельзя считать эталоном. Вот по этому я и считаю более логичным текущее поведение и например внесение файла HOSTS в исключение.изменение файла со стороны фонового сканирования
М-м-м! Давайте будем все решать за пользователя. Ведь он же мог ошибиться. Мое мнение - антивирус для пользователя, а не пользователь для антивируса. Я хочу решать на своей машине, что делать антивирусу, а не антивирус будет решать, что делать мне.
Борис А. Чертенко aka Borka.