vlad7rpk 19 сен 2013 в 07:42

Linux Malware Detect — антивирус для веб-серверов

4 мин

67K

Настройка Linux * Антивирусная защита *

Из песочницы

+31

Комментарии 48

datacompboy 19 сен 2013 в 07:51

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

redc0de 19 сен 2013 в 07:52

Находит ли простейшие шеллы?
@passthru($_GET['cmd']);

Находит ли подозрительные файлы (Допустим обфусцированные php,js скрипты) или считает их подозрительными?
И наконец, если у клиента стоит какая-то проприетарщина (обфусцированная), то как решать эту проблему?

zCooler 19 сен 2013 в 08:02

Если в базе есть, то находит. А так нет.
Новые шелы, или обфусицированные, не находит. Хотя когда джумло/вордпресс ламают, то шелы заливают не один скрипт-киддис, и одни заливают старые шелы (с99 тот-же старый), и maldet срабатывает. Заходишь в папку и наблюдаешь еще парочку неопределяемых шелов. Обычно сразу их отправляю на рассмотрение [maldet -c shell.php]

vlad7rpk 19 сен 2013 в 08:04

Находит ли простейшие шеллы?
@passthru($_GET['cmd']);

Кастомные шеллы, как этот, LMD не находит, т.к. он ищет совпадения по базе сигнатур. В нем нет анализа кода, если шелла нет в базе и в нем нет обфускации — он его не найдет.

Находит ли подозрительные файлы (Допустим обфусцированные php,js скрипты) или считает их подозрительными?

Считает их подозрительными обозначая, например, как base64.inject.unclassed

И наконец, если у клиента стоит какая-то проприетарщина (обфусцированная), то как решать эту проблему?

Ложных срабатываний, например на ZendIoncube-кодированных файлов замечено небыло.

redc0de 19 сен 2013 в 09:41

Кстате по поводу LMD (названия). Очень очень давно был конструктор вирусов — LMD (Lamer Death). :)

link0ln 19 сен 2013 в 08:24

Нда, тогда какой толк от не? взяв любой шелл и дописав в него print ""; — мы обойдем защиту.
Далее, попробовал просканить каталоги, потом поменял сожерижмое файла и запустил maldet -r /home/user1/ 2 — измененные файлы оно мне не показало. Что я сделал не так?

vlad7rpk 19 сен 2013 в 08:51

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

измененные файлы оно мне не показало. Что я сделал не так?

Либо у Вас не работает find /path -mtime, либо файла нет в сигнатурах.

ColorPrint 19 сен 2013 в 09:23

Для FreeBSD нет? (

vlad7rpk 19 сен 2013 в 09:39

К сожалению, опыта использования на FreeBSD нет.

charliez 19 сен 2013 в 11:22

Пробовали на фряхе запускать, геморой, завязано на линукс-специфичные либы…

ColorPrint 19 сен 2013 в 11:56

Пока нагуглил что вроде кто-то запускал, проблемы решились установкой баша и изменением путей до него…
Этого недостаточно на самом деле?

charliez 19 сен 2013 в 15:09

Попробовал сейчас, с поставленным и слинкованным в /bin/ башем поставилось, запускается, но что-то на скорую руку написанные бэкдоры и eval'ы оно никак не реагирует :) Ну его нафиг, буду и дальше по старинке egrep использовать :)

vlad7rpk 19 сен 2013 в 15:38

На счет кастомных шеллов ответ Выше
На такой случай лучше подойдет AIBolit

mnemonic 19 сен 2013 в 09:32

Можно их в купе с AI-BOLIT'ом использовать (http://revisium.com/ai/).

Claud 19 сен 2013 в 14:30

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

mnemonic 19 сен 2013 в 14:38

При сканировании нужно использовать whitelist — файл для конкретной CMS, он убирает большинство ложных срабатываний.

charliez 19 сен 2013 в 14:43

Недавно лечил человеку сайт, айболит вывалил кучу ложных срабатываний, невзирая на whitelist. И парочку стандартных шеллов. А egrep -r «eval|GET.*cmd » * нашел кучу зараженных бекдорами скриптов, про которые айболит ну слухом, ни духом…

past 19 сен 2013 в 10:14

А если скрипт в БД лежит?

djdb 19 сен 2013 в 10:36

Если это — репо проекта, то я не вижу исходников для поставляемых бинарей (inotifywait, libinotifytools.so.0). Нету их и в tar.gz. Это какой-то contrib?

vlad7rpk 19 сен 2013 в 10:56

Откуда эти бинари — хороший вопрос. Следует спросить об этом автора.

EuroElessar 19 сен 2013 в 11:37

Эти бинари находятся в пакетах inotify-tools и libinotifytools0 в Debian/Ubuntu, возможно автор их просто взял оттуда.

powerman 19 сен 2013 в 11:39

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

Во-первых, вместо переписывания текущей системной библиотеки /usr/lib/libinotifytools.so.0 непонятно какой версией (и как скомпилированной) просто пропишите в README зависимость от пакета inotify-tools (https://github.com/rvoicilas/inotify-tools). В Gentoo он ставится штатно через emerge sys-fs/inotify-tools, думаю в других дистрибутивах этот пакет тоже есть. Ну и таскать свой бинарник inotifywait отпадёт нужда.

Во-вторых избавьтесь от прошитого в куче мест (не только в install.sh, но и в файлах приложения) пути /usr/local/maldetect — нормальные люди всё-равно предпочтут устанавливать приложение через пакетный менеджер своего дистрибутива, а не install.sh. А разработчики пакетов для дистрибутивов предпочтут устанавливать все файлы в стандартные каталоги вроде /usr/bin/ и /etc/ — так что приложение должно быть готово либо найти свои файлы в стандартных каталогах либо брать пути к ним из конфига.

Далее, определитесь с названием продукта — maldet или lmd, какой смысл устанавливать два идентичных бинарника (точнее, бинарник и симлинк, но это не важно). Или при вызове с именем lmd приложение работает не так, как при вызове как maldet?

Про логику «обновления» в install.sh я лучше вообще промолчу. Возможно я чего-то не понимаю, но выглядит это дико и беспощадно: вечное хранение старых версий в соседних каталогах, удаление симлинка .last перед его созданием (ln это сам умеет делать), повторное создание симлинков в /usr/local/sbin/ (интересно, а почему эти решили не удалять перед созданием), копирование старых файлов из tmp/ (что, новая версия действительно нуждается в старых tmp/* файлах и без них будет работать некорректно?).

vlad7rpk 19 сен 2013 в 12:02

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

sublimelion 19 сен 2013 в 17:11

Нашел у себя «пачку»!
Спасибо!

tarya 19 сен 2013 в 19:28

maldet(5097): {scan} signatures loaded: 11272 (9400 MD5 / 1872 HEX)
maldet(5097): {scan} building file list for /var/www/xxx.org.ua, this might take awhile…
maldet(5097): {scan} file list completed, found 8630 files…
maldet(5097): {scan} 8630/8630 files scanned: 0 hits 0 cleaned
maldet(5097): {scan} scan completed on /var/www/xxx.org.ua: files 8630, malware hits 0, cleaned hits 0
maldet(5097): {scan} scan report saved, to view run: maldet --report 091913-2217.5097

В моих проектах я ничего не нашел. Приятно!

pavlinux 21 сен 2013 в 14:53

unistall.sh ещё бы.

pavlinux 21 сен 2013 в 15:00

Хотя, вроде хватит:

$ rm -rf  $instpath  /etc/cron.daily/maldet

pavlinux 21 сен 2013 в 15:09

Блин, мужики, если в скрипте заменить $instpath на $PWD, то ничё устанавливать не нужно.

public_scan=1 — чтоб не от рута пускать!

diff -ur maldetect-1.4.2.orig/files/conf.maldet maldetect-1.4.2/files/conf.maldet
--- maldetect-1.4.2.orig/files/conf.maldet      2013-04-09 11:17:30.000000000 +0400
+++ maldetect-1.4.2/files/conf.maldet   2013-09-21 18:59:49.000000000 +0400
@@ -95,7 +95,7 @@
 # quarantine, session and temporary paths to faciliate scans.
 # These paths are populated through cron every 10min with the
 # /etc/cron.d/maldet_pub cronjob.
-public_scan=0
+public_scan=1
 
 ##
 # [ STATISTICAL ANALYSIS ]
diff -ur maldetect-1.4.2.orig/files/maldet maldetect-1.4.2/files/maldet
--- maldetect-1.4.2.orig/files/maldet   2013-04-13 08:58:30.000000000 +0400
+++ maldetect-1.4.2/files/maldet        2013-09-21 18:58:48.000000000 +0400
@@ -9,7 +9,7 @@
 ##
 #
 ver=1.4.2
-inspath=/usr/local/maldetect
+inspath=$PWD
 cnf=$inspath/conf.maldet
 intcnf=$inspath/internals.conf
 datestamp=`date +"%m%d%y-%H%M"`

есессенно с inotify сами разрулите

pavlinux 21 сен 2013 в 15:49

А никто не знает, зачем этот троян сливает все к себе на FTP?

host=ftp.rfxn.com
user=anonymous
passwd=anonymous
upath=incoming


ftp -v -n -i $host << EOT
user $user@rfxn.com $passwd
prompt
cd $upath
lcd $lcd
binary
put "$file" "$RANDOM.$$.bin"
ascii
put "$file" "$RANDOM.$$.ascii"
bye
EOT

vlad7rpk 21 сен 2013 в 15:52

Опция загрузки обнаруженных потенциальных угроз на официальный сайт для анализа.

pavlinux 21 сен 2013 в 15:53

Спасибо, я выкачал рекурсивно всю директорию, сижу собираю ваши пароли к базам и сайтам :)

wget -r ftp://ftp.rfxn.com/incoming/*

vlad7rpk 21 сен 2013 в 16:17

Файлы заливаются туда руками через
#maldet -c /home/user1/file.php
и если кто-то заливает туда на проверку файлы с паролями — ССЗБ.

pavlinux 21 сен 2013 в 16:21

Ну вот например один ССЗБ уже есть :)
Надо просто запустить maldet -c /var/www, где флаг -с описан как checkout, а не send-to-remote-analyses

vlad7rpk 21 сен 2013 в 16:25

А разве он что-то загружал на rfxn для проверки?
Еще раз объясню — скрипт ничего «сам» к себе не сливает.
Для загрузки файла на проверку нужно вызвать функцию загрузки:

#maldet -c /home/user1/file.php

pavlinux 21 сен 2013 в 16:41

Еще раз объясняю, запусти

maldet --checkout /var/www/

Слово checkout переводится как проверять, а не проверить и если чо отправить на АНБшный сервер. Более того, о таких вещах надо предупреждать и делать доп. флаг (типа --yes ), дабы не спрашивать каждый раз.

vlad7rpk 21 сен 2013 в 16:37

-c, --checkout FILE
Upload suspected malware to rfxn.com for review & hashing into signatures

pavlinux 21 сен 2013 в 16:42

Нет там такого

 ./maldet 
Linux Malware Detect v1.4.2
            (C) 2002-2013, R-fx Networks <proj@r-fx.org>
            (C) 2013, Ryan MacDonald <ryan@r-fx.org>
inotifywait (C) 2007, Rohan McGovern <rohan@mcgovern.id.au>
This program may be freely redistributed under the terms of the GNU GPL v2

signature set: 201309132982
usage maldet [-h|--help] [-l|--log] [-e|--report] [-p|--purge] [-c|--checkout]
[-b|--background] [-m|--monitor] [-k|--kill-monitor] [-a|--scan-all] [-r|--scan-recent]
[-q|--quarantine] [-s|--restore] [-n|--clean] [-u|--update] [-d|--update-ver]

vlad7rpk 21 сен 2013 в 16:46

maldet --help

pavlinux 21 сен 2013 в 16:52

Если автор этой поделки такой элитный UNIXойд, то должен знать, что флаги

-a — означает ALL (все дефолтные опции),
-с — именно проверка.
-r — рекурсия
-q — quiet — тихо, без трейса, только результат или даже без него.
-d — daemon, а не -b

Единственное с чем он попал это kill и update остальное не Unix-way :)

Pilat 22 дек 2013 в 07:40

Никаких стандартных значений для этих флагов не предусмотрено, не придумывайте. -с обычно обозначает путь к конфигу или выполняемую команду, но не всегда. -a обозначает иногда все действия по какому-то принципу, но «все дефолтные опции» — это уже нонсенс, дефолтные опции и так уже установлены, -d — всё что угодно, например название базы данных.

pavlinux 21 сен 2013 в 16:45

Ах да, документацию у нас вообще-то редко кто читает :)

vlad7rpk 21 сен 2013 в 16:46

А зря.

pavlinux 21 сен 2013 в 16:15

В общем народ, стремная эта штука! Выкачаивайте свои сайты и проверяйте на тестовых компах, дома, на виртуалках…
На боевой сервер, да ещё и в крон сувать… ну не знаю, я очкую. :)

ITLav 23 сен 2013 в 14:27

Собрал пакеты под большинство систем, правильно разложив файлы согласно FHS:
download.etersoft.ru/pub/Korinf/projects/maldetect/

Прошу ставить, проверять.
Проверил на своих сайтах, и с удивлением обнаружил ряд вредных инъекций в код.

Напоролся, что если clamav установлен, а базы к нему ни разу не скачивались, то проверка молча завершится, не сказав о том, что ничего проверять не стали. При использовании clamav там вызывается clamscan, с указанием, чтобы проверять и по базам clamav и по базам maldet.