Как удалить exim4 из debian

Обновлено: 03.07.2024

Коллеги, кто использует на своих почтовых серверах Exim версий 4.87. 4.91 — срочно обновляйтесь до версии 4.92, предварительно остановив сам Exim во избежание взлома через CVE-2019-10149.

Потенциально уязвимы несколько миллионов серверов по всему миру, уязвимость оценивается как критическая (CVSS 3.0 base score = 9.8/10). Злоумышленники могут запускать на Вашем сервере произвольные команды, во многих случаях от рута.

Пожалуйста, убедитесь что Вы используете исправленную версию (4.92) либо уже пропатченную.
Либо пропатчите существующую, см. ветку комментария immaculate.

Обновление для centos 6: см. комментарий Theodor — для centos 7 оно тоже работает, если из epel напрямую еще не прилетело.

UPD: Убунту затронуты 18.04 и 18.10, обновление для них выпущено. Версии 16.04 и 19.04 не затронуты, если только кастомные варианты на них не ставили. Подробнее на их официальном сайте.

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

Далее читать актуально только для тех, кто уже «попал» — надо или перевозить всё на чистую VPS со свежим софтом, или искать решение. Попробуем? Пишите, если кто-то сможет побороть малварь эту.

Если Вы, являясь пользователем Exim и читая это, всё ещё не обновились (не убедились в наличии 4.92 или пропатченной версии), пожалуйста остановитесь и бегите обновляться.

Для уже попавших — продолжим…

Зловредов может быть великое множество. Запустив лекарство не от того и почистив очередь пользователь и не вылечится и возможно не узнает от чего ему лечиться нужно.

Заражение заметно так: [kthrotlds] грузит процессор; на слабой VDS на 100%, на серваках слабее но заметно.

После заражения зловред удаляет записи в крон, прописывая там только себя в запуском каждые 4 минуты, при этом файл кронтаба делает immutable. Crontab -e не может сохранить изменения, выдаёт ошибку.

Immutable можно снять например так, после чего удалить строку команды (1.5кб):

Далее там в редакторе crontab (vim) удаляем строку и сохраняем: dd
:wq

Однако какой-то из активных процессов перезаписывает снова, разбираюсь.

При этом висит куча активных wget'ов (либо curl'ов) на адреса из скрипта инсталлятора (см. ниже), я их пока сбиваю так, но они снова запускаются:

Скрипт инсталлятора трояна нашел тут (centos): /usr/local/bin/nptd… не выкладываю во избежание, но если кто заражен и разбирается в shell скриптах, пожалуйста изучите внимательнее.

Дополню по мере обновления информации.

UPD 1: Снос файлов (с предварительным chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root не помог, равно как и остановка службы — пришлось кронтаб пока полностью выдрать (bin-файл переименовать).

UPD 2: Инсталлятор трояна иногда валялся также в других местах, помог поиск по размеру:
find / -size 19825c

UPD 3: Внимание! Помимо отключения selinux троян также добавляет свой SSH-ключ в $/authorized_keys! И активирует следующие поля в /etc/ssh/sshd_config, если они ещё не были прописаны как YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes

UPD 4: Резюмируя на данный момент: отключаем exim, cron (с корнями), срочно убираем троянов ключ из ssh и правим конфиг sshd, перезапускаем sshd! И то пока не точно что это поможет, но без этого вообще беда.

Важную информацию из комментариев про патчи/апдейты вынес в начало заметки, чтобы читающие с неё начинали.

UPD 5: AnotherDenni пишет что малварь поменяла пароли в WordPress.

UPD 6: Paulmann подготовил временное лекарство, тестируем! После перезагрузки или отключения лекарства вроде как слетает, но пока хоть так.

Кто сделает (или найдёт) стабильное решение, пожалуйста пишите, многим поможете.

Очистить всю очередь exim можно так:
exipick -i | xargs exim -Mrm
Проверка количества записей в очереди:
exim -bpc

UPD 8: Снова спасибо за информацию AnotherDenni: FirstVDS предложили свою версию скрипта для лечения, давайте тестировать!

UPD 9: Похоже что работает, спасибо Кириллу за скрипт!

Главное не забудьте что сервер уже был скомпрометирован и злоумышленники могли успеть ещё каких-то нетиповых гадостей (не прописанных в дроппере) подсадить.

Поэтому лучше переехать на начисто установленный сервер (vds), или хотя бы продолжить отслеживать тему — если что-то будет новое, пишите в комменты здесь, т.к. явно не все будут переезжать на свежую установку…

UPD 10: Ещё раз спасибо clsv: он напоминает что заражаются не только серверы, но например и Raspberry Pi, и виртуалки всякие… Так что после спасения серверов не забудьте спасти свои видеоприставки, роботов и тд.

UPD 11: От автора целебного скрипта важное примечание для «лечащих вручную»:
(после применения того или иного метода борьбы с этим зловредом)

перезагружаться обязательно надо — малварь сидит где-то в открытых процессах и, соответственно, в памяти, и записывает себя по новой в крон каждые секунд 30

UPD 12: supersmile2009 нашел у себя в очереди exim другой(?) зловред и советует сначала изучить конкретно свою проблему, до начала лечения.

UPD 13: lorc советует скорее переезжать на чистую систему, и файлы переносить крайне осторожно, т.к. малварь уже в публичном доступе и её использовать могут другими, менее очевидными и более опасными способами.

Даже если работает не из под рута происходит взлом… У меня на OrangePi стоит debian ~~jessie~~ UPD: stretch, exim запущен от Debian-exim и все равно случился взлом, потерло крон и прочее.

UPD 15: при переезде на чистый сервер со скомпрометированного не забывайте про гигиену, полезное напоминание от w0den:

При переносе данных обратите внимание не только на исполняемые или конфигурационные файлы, но и всё что может содержать вредоносные команды (например, в MySQL это может быть CREATE TRIGGER или CREATE EVENT). Также, не забывайте о .html, .js, .php, .py и других публичных файлах (в идеале эти файлы, как и другие данные, должны быть восстановлены из локального или другого доверенного хранилища).

UPD 16: daykkin и savage_me столкнулись с другой проблемой: в системе в портах стояла одна версия exim, а на деле выполнялась другая.

Так что всем после обновления стоит убедиться что используете именно новую версию!
Конкретно с их ситуацией мы сообща разобрались.

На сервере использовался DirectAdmin и стоял его старый пакет da_exim (старой версии, без уязвимости).

При этом с помощью DirectAdmin'овского менеджера пакетов custombuild по факту потом была установлена более новая версия exim, уже уязвимая.

Конкретно в этой ситуации помогло также обновление через custombuild.

Не забывайте делать бэкапы до таких экспериментов, а также убедитесь что до/после обновления все процессы exim старой версии были остановлены и не «застряли» в памяти.

Почтовый агент Exim может выполнять функции как почтового транспортного агента (англ. Mail Transfer Agent, MTA), так и агента начального приема почты (англ. Mail submission Agent, MSA.) Он может быть настроен для автономной работы (доставки почты между пользователями системы, без обращения к Internet), для обеспечения транзита почты (без поддержки локальных почтовых ящиков), для взаимодействия с вышестоящим почтовым узлом (англ. smarthost) и без такового.

Содержание

Проектом Debian поддерживаются два варианта сборки Exim:

начального приема

Выбранный пакет можно установить используя APT, например:

При этом, если соответствующие данные не были внесены в систему Debconf ранее, будет инициирована процедура начальной настройки.

Предметом начальной настройки Exim в Debian являются файлы mailname(5) и /etc/exim/update-exim4.conf.conf . Эти файлы, разумеется, являются текстовыми, однако не подлежат непосредственному редактированию, поскольку могут быть перезаписаны при выполнении этапа настройки Debian-пакета (кодом exim4-config.config .) Поэтому, для их правки следует использовать средства Debconf, например:

В ходе начальной настройки будут заданы следующие вопросы.

почтовый узел Internet ( internet ): доставка в соответствии с DNS-записями типа MX;
«внутренний» почтовый узел ( smarthost ): доставка исходящей почты через вышестоящий почтовый узел;
только локальная доставка ( local .)

Почтовое имя системы хранится в файле mailname(5).

(список пуст — все интерфейсы системы)

::1; 127.0.0.0/8; 2001:db8:1337:cafe::/64; 192.0.2.128/25

(список пуст — все интерфейсы системы; ::1; 127.0.0.0/8 — только локальная петля)

Определяет обслуживаемые Exim сетевые интерфейсы. По-умолчанию, обслуживаются все активные (поднятые) сетевые интерфейсы системы.

Ограничивать список интерфейсов имеет смысл, главным образом, в случае использования Exim как агента начального приема почты для некоторой локальной сети, с последующей передачей почты вышестоящему почтовому узлу и получением почты извне без использования протокола SMTP (например, с помощью программы Fetchmail.) В этом случае, данный параметр будет содержать IP-адреса (и соответствующие длины сетевых префиксов) интерфейса, связывающего систему с обслуживаемой локальной сетью.

Кроме того, если обеспечение данной функции требуется лишь в пределах локальной системы, список интерфейсов можно ограничить значением ::1; 127.0.0.0/8 .

Подчеркнем, что при наличии в системе, обслуживающей локальную сеть — или доставку входящей почты через оную по протоколу SMTP — единственного (помимо локальной петли lo ) интерфейса (например, eth0 ), данный параметр является совершенно избыточным.

(список пуст — только localhost )

Определяет список доменных имен, доставка на которые выполняется в локальные почтовые ящики пользователей.

В этом списке имеет смысл упомянуть основное почтовое имя системы, ее собственное доменное имя (если отлично от основного почтового), а также все функциональные псевдонимы.

Используется только для почтовых узлов Internet (общий тип конфигурации: internet .)

Применять этот параметр имеет смысл в следующих двух случаях:

при организации вторичного почтового узла для доменного имени (или группы имен) — в этом случае, в DNS должна присутствовать по меньшей мере одна более приоритетная MX-запись для каждого из перечисленных доменных имен;
при приеме почты на почтовый шлюз, с последующим распределением по локальным почтовым узлам — для чего соответствие доменных имен и адресов локальных почтовых узлов должно быть определено файлом exim4_hubbed_hosts(5).

(список пуст — только адреса локальной петли)

(список пуст — только адреса локальной петли; для управление доступом использовать SASL, TLS, сертификаты X.509,)

Определяет список сетевых префиксов, из которых данная система будет безусловно принимать почту для последующей пересылки (иными словами — являться вышестоящим почтовым узлом, или smarthost.)

Адреса локальной петли всегда присутствуют в этом списке.

Аналогичный подход, но с использованием сертификатов X.509, можно применить и для приема почты от нижестоящих почтовых транспортных агентов (MTA.)

При исключительном использовании сверки (что рекомендуется), данный параметр следует оставить пустым.

(доменное имя вышестоящего почтового узла, если таковой используется)

Список доменных имен и адресов почтовых узлов, на которые будет отправляться исходящая почта.

Используется только если подразумевается общим типом конфигурации ( smarthost , satellite .)

Отметим, что ввиду использования одиночного двоеточия ( : ) в качестве разделителя элементов данного списка, все двоеточия, входящие в состав элементов (разделители тетрад адреса IPv6; двоеточие, предваряющее номер порта) должны быть удвоены.

mail_spool — доставка в файлы директории /var/mail/ в формате Unix mbox

maildir_home — доставка в поддиректории Maildir домашних директорий пользователей в формате Maildir

Основные проблемы, возникающие с этим форматом:

false — используется файл /etc/exim4/exim4.conf.template

true — используется директория /etc/exim4/conf.d/

В своей работе Exim пользуется единственным основным конфигурационным файлом. В Debian такой файл формируется программой update-exim4.conf(8) на основе, с одной стороны, ее собственных настроек ( update-exim4.conf.conf ), с другой стороны, — шаблона, в качестве которого может выступать или содержимое директории conf.d , или файл exim4.conf.template (который, в свою очередь, может быть создан из содержимого conf.d программой update-exim4.conf.template(8).)

Далее мы будем предполагать, что Exim использует конфигурационные файлы, содержащиеся в директории conf.d .

(доставка в /var/mail/mail )

(пользовательская учетная запись администратора)

В случае отказа от этой возможности, почта root будет доставляться в /var/mail/mail .

Кроме того, потребуется определить вышеупомянутые параметры в main -файле (например: /etc/exim4/conf.d/main/00_local_tls_client ), подобно:

Здесь мы предполагаем, что имена содержащих сертификат X.509 ( MAIN_TLS_CERTIFICATE ) и секретный ключ ( MAIN_TLS_PRIVATEKEY ) файлов, равно как и файла, содержащего доверенные сертификаты ( MAIN_TLS_VERIFY_CERTIFICATES ), уже определены используемой конфигурацией Exim. (По-умолчанию, код main/03_exim4-config_tlsoptions определяет их как CONFDIR/exim.crt , CONFDIR/exim.key и, если существует, /etc/ssl/certs/ca-certificates.crt , — но лишь при условии определения MAIN_TLS_ENABLE пользователем.)

Текущая версия Exim в Debian позволяет использовать TLS для входящих соединений, при наличии настроек, подобных нижеследующим, помещаемых в main -файл (например: /etc/exim4/conf.d/main/00_local_tls .)

В данном случае, мы разрешаем ( MAIN_TLS_ENABLE ) использование TLS для входящих соединений; используем ( MAIN_TLS_VERIFY_HOSTS ) содержимое файла tls_verify_hosts конфигурационной директории Exim ( CONFDIR , иными словами — /etc/exim4 ) в качестве списка систем, для которых проверка действительности сертификата является обязательной; а также запрашиваем ( MAIN_TLS_TRY_VERIFY_HOSTS ) выполнение такой проверки для всех без исключения входящих соединений.

По-умолчанию, необходимые для использования TLS закрытый ключ и сертификат X.509 будут загружены из файлов exim.key и exim.crt конфигурационной директории Exim, соответственно. Ради единообразия, можно поместить сертификат в директорию /etc/ssl/certs , подобно:

Использование директории /etc/ssl/private для размещения закрытого ключа (параметр MAIN_TLS_PRIVATEKEY ), по-видимому, лишено смысла, поскольку эта директория доступна только root , в то время как Exim будет выполняться от непривилегированного пользователя ( Debian-exim ) в момент обращения к файлу.

Однако, эта функциональность предназначена прежде всего для приема почты от почтовых пользовательских агентов (MUA.) Для сверки нижестоящих узлов можно воспользоваться следующим фрагментом кода, который целесообразно поместить сразу же после кода проверки на вхождение IP-адреса удаленной системы в список relay_from_hosts .

Список адресов relay_from_hosts_tls_mta , для соединений с которых будет выполнена такая сверка, указывается в main -файле, подобно (в данном примере доступ не ограничивается конкретными IP-адресами):

Список различительных имен (англ. distinguished name, DN) нижестоящих узлов помещается в файл relay_tls_dn конфигурационной директории Exim, и может быть подобен следующему:

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

Это повысит вашу безопасность. В этой статье мы рассмотрим как выполняется удаление пакетов Debian различными способами, рассмотрим как удалить пакет имя которого вы знаете, а также как удалить все ненужные пакеты из системы.

Удаление пакетов Debian

Самый простой способ удалить программу Debian, которая вам больше не нужна - это воспользоваться пакетным менеджером apt. Просто используйте команду apt remove:

$ sudo apt-get remove имя_программы

Или можно удалить все пакеты, которые касаются этой программы, например:

$ sudo apt-get remove имя_программы*

Например, удалим установленный по умолчанию почтовый клиент evolution. Если бы мы использовали звездочку, то были бы удаленны все пакеты, имя которых начинается на evolution, например, evolution-data и evolution-plugins.

sudo apt-get remove evolution

Но при таком способе удаления в системе могут оставаться конфигурационные файлы программы, а также дополнительные пакеты. Чтобы удалить конфигурационные файлы можно использовать опцию --purge или команду purge:

sudo apt-get --purge remove evolution

sudo apt-get --purge --auto-remove remove evolution

sudo apt-get purge --auto-remove evolution

Последняя команда выполняет полное удаление пакета из системы. Но чтобы удалить пакет вам нужно сначала знать его имя. Имя пакета можно узнать с помощью утилиты dpkg. Сначала ищем какие-либо файлы программы по ее названию, например, тот же evolution:

find / -name evolution

Дальше смотрим имя пакета, которому принадлежит выбранный файл:

sudo dpkg -S /usr/bin/evolution

А дальше, уже на основе полученной информации вы можете удалить лишний пакет. Рассмотрим как удалить пакет Debian с помощью dpkg, для этого есть опция -r или --remove. Но тут вам придется указать все зависимости:

sudo dpkg --remove evolution evolution-plugins

У dpkg есть свой аналог команды purge, это опция -p или --purge, которая позволяет удалить пакет Debian полностью и не оставлять никаких конфигурационных файлов в системе:

sudo dpkg --purge evolution evolution-plugins

Если пакет не удаляется потому что был поврежден или была повреждена база пакетов, а вы считаете что удаление именно этого пакета может спасти ситуацию, то используйте опцию --force-remove-reinstreq:

sudo dpkg --remove --force-remove-reinstreq имя_пакета

Также можно использовать опцию --force-depends, чтобы не удалять пакеты, которые зависят от удаляемого:

sudo dpkg -r --force-depends имя_пакета

Иногда, во время удаления пакетов, некоторые зависимости остаются в системе, например, рекомендованные пакеты. Их тоже можно удалить чтобы освободить место и не держать лишнего на компьютере. Для этого используется программа deborphan. Для начала вам нужно будет ее установить:

sudo apt-get install deborphan

Затем для поиска всех пакетов, которые можно удалить наберите:

Дальше вы можете удалить каждый пакет из списка вручную с помощью apt-get или dpkg. Если вы уже знаете, что все пакеты, которые будут удалены не нужны, то можно объединить команду deborphan с xargs и автоматически их все сразу удалить:

deborphan | xargs sudo apt-get -y remove --purge

Имя каждого пакета будет подставлено в конец строки.

Удаление пакетов в GUI

Пакеты можно удалять не только через терминал, но и через графический интерфейс. В Debian используется окружение рабочего стола Gnome, поэтому там доступен центр приложений Gnome Software. Вы можете запустить его из главного меню системы:

Затем перейдите на вкладку "Установлено":

Вам осталось выбрать приложение, которое хотите удалить, а затем нажать кнопку "Удалить":

После этого вам нужно будет ввести пароль пользователя, а затем дождаться завершения удаления. Как видите, все очень просто.

Выводы

В этой статье мы рассмотрели как выполняется удаление программ debian несколькими способами. Как видите, это достаточно просто. Если вы имеете немного опыта использования терминала, то сможете получить все его преимущества, в противном же случае можете использовать графический интерфейс. Если у вас остались вопросы, спрашивайте в комментариях!

Можно ли как-то обновить только exim4 так? Или все таки безопаснее:

Спасибо за ответы.

А до этого что было в sources.list? Ты хочешь в олдстейбл поставить exim из стейбла?

Вы после подключения репозитория wheezy делали обновления списка пакетов ?

Но, скорее всего, после обновления списка пакетов из репозитория другой ветки у вас будет так же обновляться и система. Если у вас, конечно, был другой релиз.

Сейчас стоит дебиан 6, но хотел бы поставить от дебиан 7. Насколько это реально?

Вы верно меня поняли, реально ли это?

Измените строки подключения репозитариев в source.list, так как вы сделали, и выполните dist-upgrade.

Здесь указано для обновления в случае расположения репозитария на CD/DVD дисках, но вы делайте также, правьте source.list, делайте update и dist-upgrade.

Он вроде удалит пакеты и доустановит по необходимости.

Это реально, но, возможно придётся поковыряться, если у макета обширные зависимости.

Первый вариант - прописать в sources.list и олдстейбл и стейбл. В /apt/preferences.d/ прописать приоритеты так, чтобы олдстейбл был выше, чем стейбл по значимости.

Это для всех реп, возможно, придётся посмотреть и писать отдельно по пакетам, если exim таки потребует частично притянуть зависимости из стейбла и заменить что-то уже установленное. Подробности в man apt_preferences.

После этого потребуется сделать apt-get update и попробовать поставить exim с указанием нужных реп(опция --target-release у apt-get install). Подробности в манах apt-get и всё том же apt_preferences.

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

Но мне всё-таки интересно, а почему требуется именно такое решение? Имеется какой-то софт, требующий именно олдстейбл? Может проще сделать полное обновление системы до стабильной версии?

Блин, сначала ответил, потом почитал тред. :)

Смело можно обновляться. То, что он удаляет - это не страшно. Он поставит замены. Единственный возможный косяк - это mysql, было у меня с ним так на одной из машин. Удаление не трогает сами базы данных, поэтому после обновления достаточно поставить mysql-server (без указания версии, это важно) и всё заработает. Но у меня такое было из-за танцев с версиями и предшествовавшими обновлению тестами mariadb из других источников, так что вряд ли это тебя коснётся.

Да, среди пакетов я заметил dovecot. Если сервер боевой, настоятельно рекомендую перед обновлением почитать про настройку dovecot'а версии 2. В squeeze была первая версия, wheezy использует вторую. Конфиги кардинально изменились, сразу после апгрейда не взлетит! Обновление остальных пакетов должно пройти нормально - не виду там ничего, с чем бы у меня возникли проблемы.

И последнее - при полном апгрейде лучше сидеть за той консолью, где был запущен apt-get dist-upgrade. Оно в процессе будет задавать вопросы. Можно, конечно, запустить в автоматическом режиме, но не советую.

Читайте также: