Вирус создает call файлы

[akmonk]

Сегодня в логах астериска обнаружил записи:

Код: Выделить всё

[Jul  4 06:59:47] WARNING[5083] pbx_spool.c: At least one of app or extension must be specified, along with tech and dest in file /var/spool/asterisk/outgoing/call.aay44A
[Jul  4 06:59:47] WARNING[5083] pbx_spool.c: Invalid file contents in /var/spool/asterisk/outgoing/call.aay44A, deleting
[Jul  4 06:59:47] WARNING[5083] pbx_spool.c: Failed to scan service '/var/spool/asterisk/outgoing/call.aay44A'
[Jul  4 06:59:47] WARNING[5083] pbx_spool.c: At least one of app or extension must be specified, along with tech and dest in file /var/spool/asterisk/outgoing/call.Gwl3Bb
[Jul  4 06:59:47] WARNING[5083] pbx_spool.c: Invalid file contents in /var/spool/asterisk/outgoing/call.Gwl3Bb, deleting
[Jul  4 06:59:47] WARNING[5083] pbx_spool.c: Failed to scan service '/var/spool/asterisk/outgoing/call.Gwl3Bb'

Таких записей несколько тысяч за час((
Как вычислить какой процесс и откуда их создает, чтобы его удалить?
core show version:
Asterisk 1.4.21.2 built by root @ asterisk on a i686 running Linux on 2008-08-04 16:09:25 UTC
Установлен на gentoo: Linux asterisk 2.6.34-gentoo-r1

[tma]

Скорее троян. Ненужно запускать и устанавливать непонятные файлы и программы.
Вы можете просто поменять в настройках asterisk'а путь к этому каталогу, а тот каталог удалить.
Конечно это решит только часть проблемы, т.к. так Вы не найдете кто же создает файлы.
Потом троян может быть умным и читающим конфигурационные файлы asterisk'а.

Во всех современных дистрибутивах есть средства аудита, которые считают MD5-суммы для всех файлов
и ежедневно проверяют были ли какие-нибудь изменения на FS, а затем шлют письма.

Так сразу и не придумать, как отловить. Надо пораскинуть мозгами. Вначале обезопасьте себя вышеуказанным методом.
Писать модуль для ядра для отлавливания системных вызовов я Вам рекомендовать не буду.

В RPM-based дистрибутивах, можно проверить целостность всех файлов, установленных из RPM.
Также можно написать скрипт, который проверит все файлы на принадлежность к той или иной RPM'ке.
Т.е. можно довольно-таки просто вычислить левые файлы, ну а дальше разбираться с ними.

Методов вагон, но с Gentoo я даже за деньги разбираться не буду.

[akmonk]

Я достаточно долго уже не устанавливал посторонних приложений. Где-то полгода назад был подобный троян, он залез через уязвимость в phpmyadmin, но его место-положение я вычислил по имени файла, которое взял с форума на котором его обсуждали. В логах апача я часто вижу безуспешные попытки отыскать phpmyadmin. Сейчас попробую изменить outgoing директорию, но и старую не буду пока удалять. Asterisk не будет удалить call файлы из старой директории и если вирус их за собой не почистит, заодно посмотрю что там за содержание. А какие конкретно есть приложения для аудита ФС для gentoo, Я хотел бы про них почитать поподробнее, но не знаю что искать.

[ded]

А нет ли у вас на станции дополнительных скриптов Автооповещение?
Неправильная работа такого мусора может порождать тонны call файлов.

Первый метод - установть Rootkit hunter
yum install rkhunter и научиться с ним обращаться.

Второй - посмотреть содержимое этих call файлов.- куда пытаются оригинироваться7

Третий - радикальный, изменить права доступа /var/spool/asterisk/outgoing или вообще удалить её.

[Ordghio]

версией phpmyadmin и названием папки в котором он стоял не поделитесь?

[tma]

Сейчас попробую изменить outgoing директорию, но и старую не буду пока удалять. Asterisk не будет удалить call файлы из старой директории и если вирус их за собой не почистит, заодно посмотрю что там за содержание.

Полезно будет увидеть с какими правами создаются эти файлы.
Это сильно сузит круг "подозреваемых".

А какие конкретно есть приложения для аудита ФС для gentoo

Как ded уже предложил -- Rootkit hunter например.
А просто считать и проверять MD5-сумму может банальный скрипт на bash.

Для того, чтобы не ломали через phpmyadmin, нужно просто научиться пользоваться iptables.

[akmonk]

А нет ли у вас на станции дополнительных скриптов Автооповещение?
Неправильная работа такого мусора может порождать тонны call файлов.

Первый метод - установть Rootkit hunter
yum install rkhunter и научиться с ним обращаться.

Второй - посмотреть содержимое этих call файлов.- куда пытаются оригинироваться7

Третий - радикальный, изменить права доступа /var/spool/asterisk/outgoing или вообще удалить её.

Скорее всего, я уверен на 99.9% что это тороян, потому как мне написали с техподдержки telphin'a, о подозрительной активности в ночное время. На счету было около 200р и были вызвонены за несколько минут. про 1 и 2 варианты сейчас буду читать, а 3 меня не устраивает, т.к. мои скрипты тоже используют call файлы. К тому же когда вирус активно создавал файлы, я поменял права на директорию, потом через минуту вернул обратно - вирус остановился, пока больше файлов не создавал. В логах ни одной записи permission denied не появилось.

[akmonk]

версией phpmyadmin и названием папки в котором он стоял не поделитесь?

Версия 3.2.1, находился он в папке pma

Но из вне сканировалось очень много вариантов где он мог бы находиться

[Ordghio]

Версия 3.2.1, находился он в папке pma

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

[tma]

Скорее всего, я уверен на 99.9% что это тороян, потому как мне написали с техподдержки telphin'a, о подозрительной активности в ночное время. На счету было около 200р и были вызвонены за несколько минут.

Я бы на Вашем месте провел бы аудит самого asterisk'а.
Ломают обычно его другими способами.
Тем более, что call-файл просто так никуда звонить не будет. Т.е. у Вас скорее всего внесены еще и изменения в
конфигурационные файлы.

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

Значит был демон, причем кривонаписанный. Обломавшись он просто упал.
Во-первых проверьте стартовые скрипты, он откуда-то должен запускаться.
Во-вторых запускаться он может например по крону, т.е. проверьте настройки крона (в том числе пользовательские в /var/spool/cron).
В-третьих перезагрузите сервер, если call-файлы начнут создаваться, значит демон вновь запущен -- его так будет проще найти.

В логах ни одной записи permission denied не появилось.

В логах трояна?