Дорогие участники форума!

Наш форум переведен в режим работы "только для чтения", публикация новых тем и сообщений недоступна. Мы искренне благодарны вам за то, что были с нами, но пришло время двигаться дальше.

На данный момент приобретение лицензий ESET через наш сайт недоступно.
В качестве альтернативы предлагаем антивирусные решения PRO32 — надёжную защиту от киберугроз и высокую производительность для устройств на Windows и Android.

Приглашаем вас присоединиться к новому форуму PRO32.

Для действующих клиентов ESET мы предлагаем промокод на скидку в размере 15% — ESET15. Добавьте лицензию в корзину и примените промокод при оформлении заказа.

Выбрать дату в календареВыбрать дату в календаре

1
Проблемы установки и настройки ESET mail security для GNU/Linux x86_64, Фидбек
Установил 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}/*
Результат:
Код
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
Однако! Основные бинарники - 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 содержит странное, я вообще не понял, верно это, устарело или является опечаткой:
Код
       as_eml_header_modificatio = yes/no

              type: bool

              default: no

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

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


У меня сложилось впечатление, что ESET Mail Security для Linux - продукт весьма сырой.
Изменено: Станислав Дёгтев - 27.12.2015 22:32:32
файлы зашифрованы с расширением .vault, bat encoder /CryptVault
Действительно, я ошибся. В одном скрипте 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"
файлы зашифрованы с расширением .vault, bat encoder /CryptVault
Цитата
santy написал:
если файлы зашифрованы, значит ключевая пара pub/sec была создана на стороне юзера. по алгоритму для шифрования sec key не нужен, поэтому он сразу же шифруется паб ключом злоумышленников (в итоге secring.gpg хранится в VAULT.KEY) и тщательно затирается на диске. нужен он только для расшифровки документов. но расшифровать VAULT.KEY могут только злоумышленники.

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

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


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

Можно попытаться найти в файловой системе компьютера жертвы копию secring.gpg. Этот файл можно попытаться найти по двум первым байтам в кластере 0x95 0x01 или 0x95 0x00
Но скрипт-шифровщик затирает исходный secring.gpg.
файлы зашифрованы с расширением .vault, bat encoder /CryptVault
Цитата
santy написал:
если успеете перехватить secring.gpg, то получится все расшифровать,
если не успеете, то расшифровать не получится.

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

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

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

Для такого поиска подходит чуть ли не любая программа с функцией "глубокого" восстановления удалённых файлов, в том числе и RStudio.
файлы зашифрованы с расширением .vault, bat encoder /CryptVault
Единственный способ расшифровать файлы без секретного ключа вымогателя -
найти в файловой системе компьютера жертвы копию secring.gpg. Задача
нетривиальная, если вообще выполнимая: скрипт-шифровщик затирает исходный
secring.gpg. Этот файл можно попытаться найти по двум первым байтам в
кластере 0x95 0x01 или 0x95 0x00
Для такого поиска подходит чуть ли не любая программа с функцией "глубокого" восстановления удалённых файлов.
файлы зашифрованы с расширением .vault, bat encoder /CryptVault
Цитата
santy написал:
нет, ключ злоумышленников, который нужен для расшифровки VAULT.KEY здесь не светится.  только на сервере злоумышленников.
вот кстати можно почитать разбор полетов шифровальщика
http://forum.drweb.com/index.php?showtopic=320137&page=13#entry757399

Поправочка: для расшифровки файлов нужен либо  расшифрованный 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
файлы зашифрованы с расширением .vault, bat encoder /CryptVault
Цитата
Максим Сергеевич написал:
почему интересно программа на восьмерке не отработала?

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