Перейти к содержимому


Фото
- - - - -

Спам в протоколах на временные файлы, есть ли способы борьбы?


  • Please log in to reply
11 ответов в этой теме

#1 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 14 Июль 2011 - 05:11

Всем привет,

Мучают меня достаточно большое количество сообщений вида:
14.07.11 6:03:01	/Library/Application Support/DrWeb/bin/drwebd[262]	[262] /Users/ladmin/Library/Preferences/com.apple.Safari.plist.ZIYCu9l - read error!
14.07.11 6:03:13	/Library/Application Support/DrWeb/bin/drwebd[255]	[255] /Users/leo/Library/Preferences/com.apple.finder.plist.rlQkrc4 - cannot get file attributes with error: No such file or directory
14.07.11 6:05:04	/Library/Application Support/DrWeb/bin/drwebd[527]	[527] /Users/ladmin/Library/Caches/com.apple.Safari/Webpage Previews/.FB49D8BD2997AA129A2A8565057F6F70.jpeg-hJnd - cannot get file attributes with error: No such file or directory
И т.д. и т.п. по тысячи раз на дню. Что с этим прикажете делать? Есть ли способ управления сей напастью?

Версия Dr.Web - 6.0.1 (201012070)
$ uname -a
Darwin XXXXXXXX.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

Сообщение было изменено Serge3leo: 14 Июль 2011 - 05:14


#2 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 14 Июль 2011 - 05:18

P.S.
Версия Dr.Web - 6.0.1 (201012070)
Версия Mac OS X - Snow Leopard (10.6.8)
Ядро 32-бит, Intel Core i7
$ uname -a
Darwin XXXXXXXX.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

#3 Andrew Kargalov

Andrew Kargalov

    Newbie

  • Dr.Web Staff
  • 19 Сообщений:

Отправлено 14 Июль 2011 - 15:37

А какова природа ваших страданий (мук)? Что хотелось бы сделать с сообщениями об ошибках drwebd?

Ведь для drwebd -- это полноценные ошибки (т.е. их уровень Error), для SpiderGuard -- обыденность, не стоящая упоминания в логах.

Если все вообще сообщения от drwebd в /dev/null отправлять -- не получится расследовать проблемы. Так что это не совсем вариант.

С отдельными файлом тоже плохо: мы в 6.0.0 окончательно избавились от собственных файлов логов, о которых нужно было заботиться (следить за размером, ротировать) и перешли на вывод всех сообщений в syslog. Спасибо вашим замечаниям в http://forum.drweb.com/index.php?showtopic=291968

#4 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 19 Июль 2011 - 12:15

А какова природа ваших страданий (мук)? Что хотелось бы сделать с сообщениями об ошибках drwebd?

Их много, до нескольких десятков раз в минуту, если что-то становится интересно в деле DrWeb они мешают.

Полную статистику я только что убил установкой Mac OS X Lion. Но и так сразу видно:
sh-3.2$ grep "drweb.*No such file or directory" /var/log/system.log |wc
	  61	1365   14646
sh-3.2$ uptime 
13:06  up 18 mins, 9 users, load averages: 3,39 2,97 1,89

Ведь для drwebd -- это полноценные ошибки (т.е. их уровень Error), для SpiderGuard -- обыденность, не стоящая упоминания в логах.

  • Не уверен, что это ошибка. Нет файла - нет вируса, мне так кажется;
  • Судя по частоте, данные протокольные сообщения это "SpiderGuard", т.к. они сыплются сравнительно равномерно, а не периодами, когда идёт сканирование.

Сообщение было изменено Serge3leo: 19 Июль 2011 - 12:19


#5 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 19 Июль 2011 - 12:27

P.S.
Нет, ну не похожи эти сообщения на "Сканер", а похожи на SpiDer Guard.
Jul 19 12:50:42 leom drwebd[96]: License for Internet gateways: None
Jul 19 12:50:42 leom drwebd[96]: License for file-servers: Unlimited
Jul 19 12:50:42 leom drwebd[96]: License for mail-servers: None
Jul 19 12:50:42 leom drwebd[96]: Daemon is installed, active interfaces:  /var/drweb/run/daemon.socket
Jul 19 12:50:43 leom drwebd[96]: SIGHUP received, reloading...
Jul 19 12:50:43 leom drwebd[96]: processes pool statistics: min = 0 max = 0 freetime = 0 busy max = 0 avg = 0.000000 requests for new process = 6 (0.081081 num/sec) creating fails = 0 max processing time = 40000 ms; avg = 0 ms curr = 0 busy = 0
Jul 19 12:50:43 leom drwebd[96]: Dr.Web (R) daemon for Mac OS X v6.0.1
Jul 19 12:50:43 leom drwebd[96]: Copyright (c) Igor Daniloff, 1992-2011
Jul 19 12:50:43 leom drwebd[96]: Doctor Web, Moscow, Russia
Jul 19 12:50:43 leom drwebd[96]: Support service: http://support.drweb.com
Jul 19 12:50:43 leom drwebd[96]: To purchase: http://buy.drweb.com
Jul 19 12&#58;50&#58;43 leom drwebd&#91;96&#93;&#58; Shell version&#58; 6.0.0.02020 <API&#58;2.2>
Jul 19 12&#58;50&#58;43 leom drwebd&#91;96&#93;&#58; Engine version&#58; 5.0.2.3300 <API&#58;2.2>
Jul 19 12&#58;50&#58;43 leom DrWebUpdateD&#91;93&#93;&#58; DRWUpdateTask&#58; update.pl finished with 0.
Jul 19 12&#58;50&#58;44 leom drwebd&#91;96&#93;&#58; Loading /Library/Application Support/DrWeb/bases/drwtoday.vdb - Ok, virus records&#58; 6095
Jul 19 12&#58;50&#58;44 leom drwebd&#91;96&#93;&#58; Loading /Library/Application Support/DrWeb/bases/drwdaily.vdb - Ok, virus records&#58; 2975


#6 Andrew Kargalov

Andrew Kargalov

    Newbie

  • Dr.Web Staff
  • 19 Сообщений:

Отправлено 19 Июль 2011 - 13:39

Да, конечно, эти сообщения получаются при работе SpiderGuard. В том случае, когда следует проверить некоторый файл (а он, к примеру, удаляется в этот момент): 1) SpiderGuard даёт указание drwebd просканировать файл (это минимально нагружающий систему способ) 2) drwebd не может этого сделать (No such file or directory), он не исполнил указание, это ошибка, она в логе 3) для SpiderGuard ошибка drwebd -- это ценный результат, который используется при дальнейшей обработке потенциальной угрозы.

Как я понял, идеальным решением будет не выводить в syslog ошибок сканирования из drwebd.

Насколько приемлем вариант установить syslog priority и facility для всех сообщений drwebd (чтобы перенаправить их куда-то, где бы они не мешали, но были бы доступны при необходимости)?

#7 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 20 Июль 2011 - 02:12

Да, конечно, эти сообщения получаются при работе SpiderGuard. В том случае, когда следует проверить некоторый файл (а он, к примеру, удаляется в этот момент): 1) SpiderGuard даёт указание drwebd просканировать файл (это минимально нагружающий систему способ) 2) drwebd не может этого сделать (No such file or directory), он не исполнил указание, это ошибка, она в логе 3) для SpiderGuard ошибка drwebd -- это ценный результат, который используется при дальнейшей обработке потенциальной угрозы.

Как я понял, идеальным решением будет не выводить в syslog ошибок сканирования из drwebd.

Скажем так, не выводить в протокол ошибки открытия и чтения, т.е. ошибки типа "read error", "No such file or directory" и, наверное, ещё парочка, которые были иницированны SpiDer Guard-ом.

Насколько приемлем вариант установить syslog priority и facility для всех сообщений drwebd (чтобы перенаправить их куда-то, где бы они не мешали, но были бы доступны при необходимости)?

Честно говоря, мне неизвестны точно параметры производительности подсистемы протоколированния Mac OS X. Однако по опыту других систем (Solaris, Linux) могу сказать, что отключение "priority и facility" не отменяет передачи сообщения между процессами, соответственно, расходов с этим связанных.

Типичная картина загрузки системы для интенсивного возникновения событий (тысячи сообщений в секунду): разрешена priority (есть запись в syslog.conf) - загрузка 98%, priority запрещена (строка в syslog.conf закоментированна) - 70%, нет вызова syslog() - 1 %.

Но это всё рассуждения за уменьшение расходов в идеале. Вероятно при запуске нагрузочных тестов файловых систем тысячи создаваемых/удаляемых файлов в секунду будут легко достижимы, но лично в моей жизни речь будет идти за временные файлы разнообразных компиляторов, а это не более сотен в секунду. Но я возьму эту возможную особенность на заметку (вдруг EFS будем делать).

Однако, замечу, что сообщение вида "/Users/leo/Library/Preferences/com.apple.finder.plist.rlQkrc4" вызвает подозрение о риске большой нагрузки, т.к., как я понимаю, это временные файлы при работе с defaults/plist (аналогом реестра Windows). Которая может быть весьма интенсивной.

#8 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 20 Июль 2011 - 02:23

P.S.
В общем, dtrace (и его аналоги) не зря придумали. Опять же, в идеале потенциально интересные события высокой интенсивности, лучше снабжать пробами dtrace, а не протокольными сообщениями типа LOG_INFO/LOG_DEBUG

#9 Andrew Kargalov

Andrew Kargalov

    Newbie

  • Dr.Web Staff
  • 19 Сообщений:

Отправлено 20 Июль 2011 - 13:26

Когда пользователь жалуется в техподдержку на странное поведение антивируса, реально попросить его выслать system.log (так собственно и делается). Просить его включить dtrace, воспроизвести проблему, собрать вывод и т.д. -- нереально. Так что dtrace (при всём его техническом совершенстве) -- не вариант.

Затраты ресурсов на вывод логов процессом drwebd вполне приемлемы при разных вариантах нагрузки (это тестируется), SpiderGuard тоже совершенствуется в плане корректной работы при большом количестве разных операций с файловой системой (мы работаем в этом направлении).

Вариант тонкой настройки drwebd в плане запрета/разрешения логирования отдельных видов ошибок возможен, но вряд ли в ближайших версиях.

В качестве эксперимента в 6.0.2 можно попробовать настроить поведение drwebd относительно логирования в секции [Daemon] в файле drweb32.ini (LogFileName = /dev/null или LogFileName = "syslog" и поменять SyslogFacility = "Daemon" и SyslogPriority = "Info"). (Правда в 6.0.3 этот способ работать не будет.)

#10 pig

pig

    Бредогенератор

  • Helpers
  • 10 689 Сообщений:

Отправлено 20 Июль 2011 - 15:47

В порядке бреда: тот, кто "заказывает музыку" (SpiderGuard или другое приложение), может передавать демону некие флаги, разрешающие игнорировать ошибки определённых категорий. Правда, это тянет за собой изменение протокола.
Альтернативный вариант: заказчик может сказать демону "молчи, я сам веду логи".
Почтовый сервер Eserv тоже работает с Dr.Web

#11 Serge3leo

Serge3leo

    Newbie

  • Posters
  • 66 Сообщений:

Отправлено 28 Июль 2011 - 09:09

Вариант тонкой настройки drwebd в плане запрета/разрешения логирования отдельных видов ошибок возможен, но вряд ли в ближайших версиях.

В качестве эксперимента в 6.0.2 можно попробовать настроить поведение drwebd относительно логирования в секции [Daemon] в файле drweb32.ini (LogFileName = /dev/null или LogFileName = "syslog" и поменять SyslogFacility = "Daemon" и SyslogPriority = "Info"). (Правда в 6.0.3 этот способ работать не будет.)

Насколько приемлем вариант установить syslog priority и facility для всех сообщений drwebd (чтобы перенаправить их куда-то, где бы они не мешали, но были бы доступны при необходимости)?

Лично мне от такого варианта: перенаправление всех ошибок Dr.Web, ни холодно, ни жарко. Я их и так отфильтрую, единственная потенциальная польза - размеры протоколов, но мы же в Mac OS X, а не на встроенной системе. В настройках newsyslog.conf по умолчанию нет ограничений на размеры протокола, только "авторотация".

Лично мне приходилось иногда сталкиваться с "реальными" ошибками Dr.Web (или кривой конфигурации), а вот способа отличить "реальные" ошибки от "фантомных" я пока не осознал.

Правильно ли я понял, что ошибки в протоколе вида:
14.07.11 6&#58;03&#58;01	/Library/Application Support/DrWeb/bin/drwebd&#91;262&#93;	&#91;262&#93; /Users/ladmin/Library/Preferences/com.apple.Safari.plist.ZIYCu9l - read error!
14.07.11 6&#58;03&#58;13	/Library/Application Support/DrWeb/bin/drwebd&#91;255&#93;	&#91;255&#93; /Users/leo/Library/Preferences/com.apple.finder.plist.rlQkrc4 - cannot get file attributes with error&#58; No such file or directory
14.07.11 6&#58;05&#58;04	/Library/Application Support/DrWeb/bin/drwebd&#91;527&#93;	&#91;527&#93; /Users/ladmin/Library/Caches/com.apple.Safari/Webpage Previews/.FB49D8BD2997AA129A2A8565057F6F70.jpeg-hJnd - cannot get file attributes with error&#58; No such file or directory
создаются только SpiDer Guard-ом, а при работе "Сканера" ошибки будут идти от другого процесса - "drweb"?

Соответственно, в качестве обхода проблемы можно не использовать "Консоль", а с помощью egrep отфильтровать по образцу: ' drwebd\[.*(- read error|: No such file or directory)'

P.S.
Я так и не понял в чём ценность этих протокольных сообщений, но Вам виднее. Однако, если есть возможно описать эту ценность в двух словах, то было бы интересно услышать в чём она состоит.

#12 Andrew Kargalov

Andrew Kargalov

    Newbie

  • Dr.Web Staff
  • 19 Сообщений:

Отправлено 01 Август 2011 - 15:41

P.S.
Я так и не понял в чём ценность этих протокольных сообщений, но Вам виднее. Однако, если есть возможно описать эту ценность в двух словах, то было бы интересно услышать в чём она состоит.


Ценность сообщений возникающих от drwebd о несуществующих и пустых файлах при работе SpiderGuard нулевая. Но пока нет способа запретить drwebd лог именно этих сообщений. Есть способ отключить все сообщения об ошибках drwebd, но это неприемлемо.


Читают тему: 1

0 пользователей, 1 гостей, 0 скрытых