Установил ESET mail security версии 4.5.3 на 64-битный линукс-дистрибутив Altlinux p7. Пришлось повозиться.

1. Сначала попробовал развернуть esets.amd64.tgz.bin
Сразу натолкнулся на ошибку выполнения /opt/eset/esets/sbin/esets_lic с невнятной диагностикой: в динамической библиотеке нет нужного вызова.
В голове сразу возник вопрос: какого рожна в универсальном пакете делают динамические бинарники и нет списка зависимостей? Явная недоработка.

2. Поскольку Altlinux это RPM-based distributive, попытался установить esets.x86_64.rpm.bin, пусть он для redhat, в RPM хотя бы зависимости можно вычислить.
Установка естественно прервалась на этапе выполнения rpm -i esets-4.5.3.x86_64.rpm
Я попробовал поставить требуемое, но пришлось подумать, пока я не догадался: распаковал этот rpm и выполнил file opt/eset/esets/{sbin,bin}/*
Результат:[CODE]opt/eset/esets/sbin/esets_daemon: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
opt/eset/esets/sbin/esets_inst:   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
opt/eset/esets/sbin/esets_lic:    ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
opt/eset/esets/sbin/esets_quar:   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
opt/eset/esets/sbin/esets_scan:   ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
opt/eset/esets/sbin/esets_set:    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
opt/eset/esets/sbin/esets_setup:  Bourne shell script text executable
opt/eset/esets/sbin/esets_update: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
opt/eset/esets/bin/esets_cgp:     ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
opt/eset/esets/bin/esets_cli:     ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
opt/eset/esets/bin/esets_mda:     ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
opt/eset/esets/bin/esets_pipe:    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
opt/eset/esets/bin/esets_zmfi:    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
[/CODE]Однако! Основные бинарники - x86, а не x86_64.
После этого установил пакет i586-glibc-gconv-modules (именно в нём содержится отсутствовавший /usr/lib/gconv/UTF-16.so) и дальше всё получилось.

3. Во время настройки очень сильно мешало отсутствие подробной документации.
3.1. Страница man esets.cfg не соответствует комментариям в esets.cfg.
3.2. Страница man esets.cfg содержит странное, я вообще не понял, верно это, устарело или является опечаткой:[CODE] as_eml_header_modificatio = yes/no

             type: bool

             default: no

             Add a new headers appended by antispam into email.
[/CODE]3.2. В веб-интерфейсе присутствуют далеко не все параметры конфигурации, например, невозможно настроить сервер прокси

4. С диагностикой неполадок полный швах. К примеру, esets_update, запущенный с опцией --verbose, сообщает ровно столько же, сколько и без этой опции. Если бы хотя бы коды возврата для него были описаны! Но нет, догадывайся, как можешь.


У меня сложилось впечатление, что ESET Mail Security для Linux - продукт весьма сырой.

Действительно, я ошибся. В одном скрипте CONFIRMATION.KEY создаётся два раза, первый раз из secring, второй - уже из списка файлов. В другом - только во втором варианте. Видимо автор исправил ошибку.

Вот у меня на руках шифрующий скрипт, от которого пострадала опрометчивая г. бухгалтер.
(сначала идёт номер строки, Cellar - имя локальной пары ключей, VaultCrypt - имя ключа вымогателя)

59 "%temp%\svchost.exe" -r Cellar --export-secret-keys --yes --homedir "%temp%" -a> "%temp%\vaultkey.vlt"
198 "%temp%\svchost.exe" -r VaultCrypt --yes -q --no-verbose --trust-model always -o "%temp%\VAULT.KEY" -e "%temp%\vaultkey.vlt"
199 "%temp%\svchost.exe" -r VaultCrypt --yes -q --no-verbose --trust-model always -o "%temp%\CONFIRMATION.KEY" -e "%temp%\confclean.list"

[QUOTE]santy написал:
если файлы зашифрованы, значит ключевая пара pub/sec была создана на стороне юзера. по алгоритму для шифрования sec key не нужен, поэтому он сразу же шифруется паб ключом злоумышленников (в итоге secring.gpg хранится в VAULT.KEY) и тщательно затирается на диске. нужен он только для расшифровки документов. но расшифровать VAULT.KEY могут только злоумышленники.

без secring.gpg расшифровать доки не получится, а без теневой копии и восстановить нельзя.

остается еще поискать специализированными утилитами среди удаленных файлов.[/QUOTE]


VAULT.KEY - это не secring.gpg, это зашифрованный экспортированный из него секретный ключ. secring.gpg зашифрован в CONFIRMATION.KEY.

Можно попытаться найти в файловой системе компьютера жертвы копию secring.gpg. Этот файл можно попытаться найти по двум первым байтам в кластере 0x95 0x01 или 0x95 0x00
Но скрипт-шифровщик затирает исходный secring.gpg.

[QUOTE]santy написал:
если успеете перехватить secring.gpg, то получится все расшифровать,
если не успеете, то расшифровать не получится.

по восстановлению докуметнтов проверьте возможность восстановить из теневой копии. эта функция поддерживается для вашей системы
[QUOTE]uVS v3.85.3 [ [URL=http://dsrt.dyndns.orgamp;#93]http://dsrt.dyndns.org][/URL] ;: Windows 7 Professional x64 (NT v6.1) build 7601 Service Pack 1 [C:\WINDOWS][/QUOTE]
другое дело, включена ли защита системы для дисков или нет.[/QUOTE]

Скрипт secured.bat удаляет теневые копии. Поэтому такое восстановление невозможно.

Единственный способ расшифровать файлы без секретного ключа вымогателя - найти в файловой системе компьютера жертвы копию secring.gpg. Задача  нетривиальная, если вообще выполнимая: скрипт-шифровщик затирает исходный secring.gpg. Этот файл можно попытаться найти по двум первым байтам в кластере 0x95 0x01 или 0x95 0x00

Для такого поиска подходит чуть ли не любая программа с функцией "глубокого" восстановления удалённых файлов, в том числе и RStudio.

Единственный способ расшифровать файлы без секретного ключа вымогателя -
найти в файловой системе компьютера жертвы копию secring.gpg. Задача
нетривиальная, если вообще выполнимая: скрипт-шифровщик затирает исходный
secring.gpg. Этот файл можно попытаться найти по двум первым байтам в
кластере 0x95 0x01 или 0x95 0x00
Для такого поиска подходит чуть ли не любая программа с функцией "глубокого" восстановления удалённых файлов.

[QUOTE]santy написал:
нет, ключ злоумышленников, который нужен для расшифровки VAULT.KEY здесь не светится.  только на сервере злоумышленников.
вот кстати можно почитать разбор полетов шифровальщика
[URL=http://forum.drweb.com/index.php?showtopic=320137amp;page=13#entry757399]http://forum.drweb.com/index.php?showtopic=320137&page=13#entry757399[/URL] [/QUOTE]

Поправочка: для расшифровки файлов нужен либо  расшифрованный VAULT.KEY, либо расшифрованный CONFIRMATION.KEY.
CONFIRMATION.KEY - это secring.gpg, зашифрованный ключом вымогателя.
VAULT.KEY - это экспортированный из secring.gpg секретный ключ Cellar (уникальный для каждого компьютера-жертвы), также зашифрованный ключом вымогателя.
Публичный ключ вымогателя есть в тексте скрипта secured.bat, это ключ B6DAB2C0 VaultCrypt (VaultCrypt) <BM-NBJaxrt4riuVrCq5NVcLrFC5CYCYkxpm@Bitmessage> длиной 1024 бита.

Единственный способ расшифровать файлы без секретного ключа вымогателя - найти в файловой системе компьютера жертвы копию secring.gpg. Задача нетривиальная, если вообще выполнимая: скрипт затирает исходный secring.gpg. Этот файл можно попытаться найти по двум первым байтам в кластере 0x95 0x01 или 0x95 0x00

[QUOTE]Максим Сергеевич написал:
почему интересно программа на восьмерке не отработала?[/QUOTE]

Потому что для шифрования используется GNUPG.EXE, скомпилированный тогда, когда Windows 8 только в проекте был.