После установки не забудьте пожалуйста перезапустить уже запущенные процессы exim, чтобы убедиться что дырявая версия не на ходу.
Касательно проверок на следы… попробуйте глянуть, не меняли ли Вам настройки ssh ( /etc/ssh/sshd_config ) и не появился ли ключ неопознанный в файле authorized_keys (или сам такой файл, если его не было); в первую очередь в /root/.ssh/authorized_keys, но для верности можно и весь диск осмотреть —
find / -name "authorized_keys"
Опять же, если ничего подозрительного нет, это ещё не гарантия чистоты, но по крайней мере значит что нет следов того дроппера, который народ тут массово ловил.
1) хабр может тоже неплохо затягивать и время поедать ;)
2) тишина для работы — не пробовали коворкинги (с тихими залами как раз для желающих тишины) или даже библиотеку?..
3) «пробовать фреймворк для hello world» без конкретной реальной цели — а оно вообще работает!? :)
Это же всё просто инструменты, их сейчас много, смысл коня в вакууме учить, если не планируется применять. Так что план про vue (+nuxt? как вариант) в следующем реальном проекте — отличная идея!
4) на upwork теряли рейтинг из-за непододящих проектов — насколько помню, top rated могут изредка удалять отзывы (т.е. останется что был проект, но будет написано что отзыв удалён + в рейтинге учитываться не будет)
5) про «в возрасте тяжело обучаться» — сохраните свой коммент, почитайте его через 10 лет, через 20 (...), посмеётесь ;) ну и тут комментов выше достаточно от тех кто в куда более старшем возраста только начинает
Так что выше нос ;)) Всё зависит только от Вас, и от того найдёте ли что-то такое же интересное… как копание в BIOS в своё время. :)
Почему же не получится его обновить, можно так же руками и обновить — бинарники вручную заменить и тд.
Сути это не поменяет — конфиги и тд главное сохраните обязательно заранее. И в идеале поставить чистые конфиги от новой версии, а в них уже руками добавить нужные настройки из старой.
Там есть полностью ручной подход, а также вариант с использованием их функционала под названием custombuild — к сожалению не пользовался D.A., но могу предположить что это их внутренний менеджер пакетов. И возможно им пропавший админ и пользовался.
А вот тут для этого самого custombuild у них есть и свежий (который уже без дыры) exim 4.92
Ха, т.е. da_exim в том же хранилище у них 4.89, новее нету. И тут же рядышком другая ветка с 4.92…
Почти уверен теперь что Ваш админ custombuild этот и использовал.
Пробуйте, только обязательно все бэкапы сначала сохраните надежно :) (никогда не устаю это повторять)
Огромными потоки-то были и во времена бибиэсок всяких (в тонкости можно было лезть далеко и надолго… свистеть по телефону только так быстро не получалось (с) ), тут думаю скорее играет роль тот факто что есть уже понимание что большая (или даже бОльшая) часть этого потока «технологий» пронесётся бурно но стремительно, и зачастую напрямую в канализацию :)
И как бы нет желания тратить ограниченное время на всякую чешую, о которой завтра никто и не вспомнит — есть много дел поинтереснее.
Ну а с другой стороны как раз-таки большое количество дел и общая информационная перегрузка не помогают учить что-то новое. А Вы не пробовали себя насильно из рутины выдернуть и, например, сесть в отпуске в деревне без телефона (условно) и без соцсеток всяких — тупо поизучать конкретную технологию совершенно новую и для Вас сложную?
Мне почему-то кажется (ок, из опыта в том числе) что оно может сработать, т.е. вопрос не в сложности обучения как такового («ой мозги не те уже, ах не те») а в слишком низком приоритете процесса и плохом соотношении сигнал/шум во время обучения.)
Понятно. Да, yum тут никак не поможет)
Раз человек пропал, сейчас наверно уже сложно понять, с какой целью он руками (?) ставил отдельный exim 4.90_1 (который сейчас и работает один).
Могу только предположить что он хотел поставить свежую версию, с da_exim либо не разобрался либо увидел что у них последний вариант был более древний (4.89) и героически свежее (на тот момент) руками накатал.
На данный момент вижу два вопроса:
1) не поломали ли Вас уже (боюсь что точный ответ даже после анализа дать будет сложно, т.к. злоумышленники могли залезть и «спрятаться» до лучшего часа, чтобы их не прибежали лечить)
2) насколько вообще критична роль у exim в Ваших процессах
В общем, навскидку, хорошо бы exim-зоопарк убрать, сохранив все конфиги/ящики и тд в бэкапы. И поставить свежий из репозиториев — благо, там уже в epel 4.92 вышел по-моему, epel-testing не нужен.
И конфиги/ящики аккуратно вернуть.
Но ещё раз подчеркну что проблема тут может быть глубже, т.к. нет никакой гарантии что дыркой уже не воспользовались… т.е. лучше бы конечно начисто поставить всё.
А пока — самое время убедиться что у Вас все свежие бэкапы есть всех данных и тд (и как минимум в паре разных мест и тд).
2) убедитесь, все ли экземпляры exim запущены из одного и того же места (в данном примере /usr/sbin/exim)
3) напрямую посмотрите версию, с указанием этого пути; в данном примере:
/usr/sbin/exim --version
Скорее всего, там будет то же самое (4.90_1), но стоит проверить и убедиться.
4) ну и ещё для проверки дубликатов в yum на всякий случай:
Отлично, да, это какой-то нетиповой exim. Я такого, честно говоря, даже не видел :) Вставьте сюда, пожалуйста, что ответит
yum info da_exim
Но уже два вывода:
1) Вам нужно обновлять не yum update exim, а yum update da_exim
2) Не спешите обновлять пока, т.к. конкретно обсуждаемая тут уязвимость Вашу версию exim не затрагивает! (про другие не поручусь) Т.к. ей затронуты версии 4.87 — 4.91. А у Вас старенькая 4.84, там этой дыры ещё не было.
При этом yum info da_exim выдаст инфу и по текущей версии, и по наличию более свежей (если есть) — посмотрим, какую там предложит.
UPD: оглянулся, надо полагать Вы используете Direct Admin? И Exim через них ставили?
UPD2: смотрю, у них в хранилище валяются разные версии da_exim, из тех что есть можно ставить 4.86.2-1 — но не более свежие! т.к. самая свежая похоже что 4.89.1-1 полуторалетней давности, и её как раз взломают
Так что либо вообще не трогать сейчас (если планируете в обозримом будущем на свежий сервак переезжать, с более новым софтом), либо обновляться конкретно до 4.86.2-1 — имхо
1) У Вас centos 6?
1) Какой стоит сейчас exim и откуда?
yum info exim
Name: exim
Arch: x86_64
Version: 4.92
Release: 1.el6
Size: 4.4 M
Repo: installed
From repo: epel-testing
3) файл репозитория epel-testing есть?
cat /etc/yum.repos.d/epel-testing.repo
4) в этом файле в блоке [epel-testing] сейчас что написано в строке mirrorlist (если она есть)?
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=testing-epel6&arch=$basearch
5) если всё вроде как есть, но не обновляет (тут в комментах пару случаев было, когда в зеркале репозитория не было свежего exim), попробуйте в mirrorlist прописать вручную другое зеркало
Ну что Вы, как можно так не по-хипсторски! Без AI, по старинке, пацаны засмеют (с) :)
А если серьёзно, тут скорее был стёб на тему того что чрезмерно умный компьютер с ещё большими тормозами как следствие чьих-то благих намерений будет очень уж сильно работе мешать, прерывая процесс своими (зачастую неуместными) замечаниями.
Современные инструменты, в частности упомянутый Вами, очень хороши и полезны — когда применяются вовремя и по делу, а не выносят мозг постоянным тормозом (см. последнюю фразу у DrPass, двумя комментами выше). :)
Веб тут не при делах, и без веба ломается. Уязвимость почтового сервера exim, подробности опубликованы в оригинальном отчёте (на англ.)
Вкратце — шлют письмо на специально составленный адрес на Вашем домене. Собственно, в некоторых случаях этого уже достаточно.
Если нет — недельку держат коннект открытым, каждые 4 минуты кидая по байту во избежание таймаута. Нужно чтобы 2-дневный лимит недоставленных писем обойти. Все детали в отчёте, все периоды — для конфига по умолчанию.
А далее — всё, RCE (удаленное выполнение команд), причём от рута. Там уже делают что им захочется.
Вот кстати интересно Вы подметили… обновлённую-то версию гадость из очереди уже не должна зацепить. Т.е. чисто логически это по идее лишний шаг. Любопытное наблюдение!
Ну вот да. Почему ещё программист!? Потому что нравится, и если бы за работу приходилось ещё самостоятельно приплачивать, то «купил» бы программист себе такую же работу — потому ей и занят независимо от возраста (т.к. мало того что по приколу, так за это ещё и платят) :) Т.е. интерес который в 10 лет был, примерно он же и в 60, в чём особо разница-то. А если интереса не было, то всё как Вы описали)
Спасибо! По логам тут по-моему достаточно grep {run rej*, по крайней мере тот вариант со zgrep мне ничего нового не показал…
С кастомным fail2ban Вы молодец, не зря свой хлеб едите) У меня вот их пропустило спокойно.
Впрочем, сам по себе пропуск такого письма судя по всему не должен был привести к поражению — локально оно бы сработало, а вот удалённо (в типовом случае) не должно было из-за включенного по умолчанию «verify = recipient».
Это не я такой умный придумал, а про 7 дней нашел источник, там эти и другие сочнейшие детали. А то все как попугаи про «по байту целую неделю» говорили, но откуда оно — меня интриговало…
А оно, собственно, из оригинального расследования — отчёта Qualys.
Очень любопытное чтиво на самом деле. 7 дней там взялись из необходимости в течение дефолтного timeout_frozen_after после отправки своего письма поддерживать открытым тоннель с 5-минутным таймаутом, так что раз в 4 минуты по байту в него кидали.
Иначе бы из заход порубился через 2 суток (ignore_bounce_errors_after).
Но, возможно, daykkin сможет что-то дополнить из своего опыта.
И главное про бэкапы не забудьте пожалуйста до эксперимента)
После установки не забудьте пожалуйста перезапустить уже запущенные процессы exim, чтобы убедиться что дырявая версия не на ходу.
Касательно проверок на следы… попробуйте глянуть, не меняли ли Вам настройки ssh ( /etc/ssh/sshd_config ) и не появился ли ключ неопознанный в файле authorized_keys (или сам такой файл, если его не было); в первую очередь в /root/.ssh/authorized_keys, но для верности можно и весь диск осмотреть —
Опять же, если ничего подозрительного нет, это ещё не гарантия чистоты, но по крайней мере значит что нет следов того дроппера, который народ тут массово ловил.
Удачи!
2) тишина для работы — не пробовали коворкинги (с тихими залами как раз для желающих тишины) или даже библиотеку?..
3) «пробовать фреймворк для hello world» без конкретной реальной цели — а оно вообще работает!? :)
Это же всё просто инструменты, их сейчас много, смысл коня в вакууме учить, если не планируется применять. Так что план про vue (+nuxt? как вариант) в следующем реальном проекте — отличная идея!
4) на upwork теряли рейтинг из-за непододящих проектов — насколько помню, top rated могут изредка удалять отзывы (т.е. останется что был проект, но будет написано что отзыв удалён + в рейтинге учитываться не будет)
5) про «в возрасте тяжело обучаться» — сохраните свой коммент, почитайте его через 10 лет, через 20 (...), посмеётесь ;) ну и тут комментов выше достаточно от тех кто в куда более старшем возраста только начинает
Так что выше нос ;)) Всё зависит только от Вас, и от того найдёте ли что-то такое же интересное… как копание в BIOS в своё время. :)
Ну вопрос на самом деле важный, будем надеяться что люди какие-то полезные примеры и подходы себе тут накопают.
Сути это не поменяет — конфиги и тд главное сохраните обязательно заранее. И в идеале поставить чистые конфиги от новой версии, а в них уже руками добавить нужные настройки из старой.
Тем временем, смотрите что я нашел:
Т.к. используете directadmin, вот их гайд по установке exim вручную (на англ конечно).
Там есть полностью ручной подход, а также вариант с использованием их функционала под названием custombuild — к сожалению не пользовался D.A., но могу предположить что это их внутренний менеджер пакетов. И возможно им пропавший админ и пользовался.
А вот тут для этого самого custombuild у них есть и свежий (который уже без дыры) exim 4.92
Ха, т.е. da_exim в том же хранилище у них 4.89, новее нету. И тут же рядышком другая ветка с 4.92…
Почти уверен теперь что Ваш админ custombuild этот и использовал.
Пробуйте, только обязательно все бэкапы сначала сохраните надежно :) (никогда не устаю это повторять)
Огромными потоки-то были и во времена бибиэсок всяких (в тонкости можно было лезть далеко и надолго… свистеть по телефону только так быстро не получалось (с) ), тут думаю скорее играет роль тот факто что есть уже понимание что большая (или даже бОльшая) часть этого потока «технологий» пронесётся бурно но стремительно, и зачастую напрямую в канализацию :)
И как бы нет желания тратить ограниченное время на всякую чешую, о которой завтра никто и не вспомнит — есть много дел поинтереснее.
Ну а с другой стороны как раз-таки большое количество дел и общая информационная перегрузка не помогают учить что-то новое. А Вы не пробовали себя насильно из рутины выдернуть и, например, сесть в отпуске в деревне без телефона (условно) и без соцсеток всяких — тупо поизучать конкретную технологию совершенно новую и для Вас сложную?
Мне почему-то кажется (ок, из опыта в том числе) что оно может сработать, т.е. вопрос не в сложности обучения как такового («ой мозги не те уже, ах не те») а в слишком низком приоритете процесса и плохом соотношении сигнал/шум во время обучения.)
Раз человек пропал, сейчас наверно уже сложно понять, с какой целью он руками (?) ставил отдельный exim 4.90_1 (который сейчас и работает один).
Могу только предположить что он хотел поставить свежую версию, с da_exim либо не разобрался либо увидел что у них последний вариант был более древний (4.89) и героически свежее (на тот момент) руками накатал.
На данный момент вижу два вопроса:
1) не поломали ли Вас уже (боюсь что точный ответ даже после анализа дать будет сложно, т.к. злоумышленники могли залезть и «спрятаться» до лучшего часа, чтобы их не прибежали лечить)
2) насколько вообще критична роль у exim в Ваших процессах
В общем, навскидку, хорошо бы exim-зоопарк убрать, сохранив все конфиги/ящики и тд в бэкапы. И поставить свежий из репозиториев — благо, там уже в epel 4.92 вышел по-моему, epel-testing не нужен.
И конфиги/ящики аккуратно вернуть.
Но ещё раз подчеркну что проблема тут может быть глубже, т.к. нет никакой гарантии что дыркой уже не воспользовались… т.е. лучше бы конечно начисто поставить всё.
А пока — самое время убедиться что у Вас все свежие бэкапы есть всех данных и тд (и как минимум в паре разных мест и тд).
Чтобы понять, это другой человек руками ставил, или например панель там решила сама установить/обновить и т.п.
Пока стоит убедиться, что активно используется именно 4.90. Пожалуйста, посмотрите:
1) откуда процессы exim запущены?
там будут строки наподобие
2) убедитесь, все ли экземпляры exim запущены из одного и того же места (в данном примере /usr/sbin/exim)
3) напрямую посмотрите версию, с указанием этого пути; в данном примере:
Скорее всего, там будет то же самое (4.90_1), но стоит проверить и убедиться.
4) ну и ещё для проверки дубликатов в yum на всякий случай:
1) Вам нужно обновлять не yum update exim, а yum update da_exim
2) Не спешите обновлять пока, т.к. конкретно обсуждаемая тут уязвимость Вашу версию exim не затрагивает! (про другие не поручусь) Т.к. ей затронуты версии 4.87 — 4.91. А у Вас старенькая 4.84, там этой дыры ещё не было.
При этом yum info da_exim выдаст инфу и по текущей версии, и по наличию более свежей (если есть) — посмотрим, какую там предложит.
UPD: оглянулся, надо полагать Вы используете Direct Admin? И Exim через них ставили?
UPD2: смотрю, у них в хранилище валяются разные версии da_exim, из тех что есть можно ставить 4.86.2-1 — но не более свежие! т.к. самая свежая похоже что 4.89.1-1 полуторалетней давности, и её как раз взломают
Так что либо вообще не трогать сейчас (если планируете в обозримом будущем на свежий сервак переезжать, с более новым софтом), либо обновляться конкретно до 4.86.2-1 — имхо
Попробуйте пожалуйста
1) Какой стоит сейчас exim и откуда?
3) файл репозитория epel-testing есть?
4) в этом файле в блоке [epel-testing] сейчас что написано в строке mirrorlist (если она есть)?
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=testing-epel6&arch=$basearch
5) если всё вроде как есть, но не обновляет (тут в комментах пару случаев было, когда в зеркале репозитория не было свежего exim), попробуйте в mirrorlist прописать вручную другое зеркало
Те же косяки репозиториев не так уж маловероятны, прямо вот тут рядом в комментах были: и с CentOS и с Debian.
Или вот у человека exim из epel, а epel вообще отключен)
Вообще в связи с этим пара мыслей —
1) м.б. сравнивать версию exim до и после попытки обновления?
2) и если не обновилась, и до сих пор попадает в уязвимый диапазон, предупреждать что мол проверьте руками, что там такое?
М.б. ради интереса попробуете например
А если серьёзно, тут скорее был стёб на тему того что чрезмерно умный компьютер с ещё большими тормозами как следствие чьих-то благих намерений будет очень уж сильно работе мешать, прерывая процесс своими (зачастую неуместными) замечаниями.
Современные инструменты, в частности упомянутый Вами, очень хороши и полезны — когда применяются вовремя и по делу, а не выносят мозг постоянным тормозом (см. последнюю фразу у DrPass, двумя комментами выше). :)
Вкратце — шлют письмо на специально составленный адрес на Вашем домене. Собственно, в некоторых случаях этого уже достаточно.
Если нет — недельку держат коннект открытым, каждые 4 минуты кидая по байту во избежание таймаута. Нужно чтобы 2-дневный лимит недоставленных писем обойти. Все детали в отчёте, все периоды — для конфига по умолчанию.
А далее — всё, RCE (удаленное выполнение команд), причём от рута. Там уже делают что им захочется.
https://habr.com/ru/company/flant/blog/454700/
С кастомным fail2ban Вы молодец, не зря свой хлеб едите) У меня вот их пропустило спокойно.
Впрочем, сам по себе пропуск такого письма судя по всему не должен был привести к поражению — локально оно бы сработало, а вот удалённо (в типовом случае) не должно было из-за включенного по умолчанию «verify = recipient».
Это не я такой умный придумал, а про 7 дней нашел источник, там эти и другие сочнейшие детали. А то все как попугаи про «по байту целую неделю» говорили, но откуда оно — меня интриговало…
А оно, собственно, из оригинального расследования — отчёта Qualys.
Очень любопытное чтиво на самом деле. 7 дней там взялись из необходимости в течение дефолтного timeout_frozen_after после отправки своего письма поддерживать открытым тоннель с 5-минутным таймаутом, так что раз в 4 минуты по байту в него кидали.
Иначе бы из заход порубился через 2 суток (ignore_bounce_errors_after).
Почитайте, прямо настоящий детектив :)