Комментарии 26
Вы абсолютно правы. В процессе написания статьи я нашёл кучу способов сделать это в пару строчек, не прибегая к использованию такого огромного количества инструментов.
Хоть я и написал в заголовке статьи, что основная цель - это отправлять уведомления после логина на сервер, но я также хотел рассказать и сам также "пощупать" Ansible и конфигурационные файлы Grafana компонентов. На примере этой статьи можно развернуть свой Ansible Playbook, настроить Promtail для любого другого файла или примерно понять как настроить компоненты Grafana Alerting.
Извините, а почему нельзя просто прописать скрипт отправки уведомлений в .bashrc? Он как раз при каждом входе выполняется
Или пересылать системные логи, auth и т.д.
Вы абсолютно правы. В процессе написания статьи я нашёл кучу способов сделать это в пару строчек, не прибегая к использованию такого огромного количества инструментов.
Хоть я и написал в заголовке статьи, что основная цель - это отправлять уведомления после логина на сервер, но я также хотел рассказать и сам также "пощупать" Ansible и конфигурационные файлы Grafana компонентов. На примере этой статьи можно развернуть свой Ansible Playbook, настроить Promtail для любого другого файла или примерно понять как настроить компоненты Grafana Alerting.
Не, скрипт отправки уведомлений лучше прописать в /etc/profile.
В этой статье решение с самого начала неудачно выбрано для задачи. Если задача "узнать о том, что кто-то заходит на сервер", то вы своим решением перенесли узкое звено на локи и графану, развернутую в единственном числе. Так, достаточно иметь в нерабочем состоянии любой из этих компонентов - promtail, loki, grafana, сеть между ними - чтобы не получить алерт. Вы слишком удлиннили пайплайн доставки, о чем вам говорят выше. Верный же подход - максимально этот пайплайн сократить. Когда такая задача стояла у меня, то я пришел к решению с отправкой вебхуком напрямую, где скрипт, дергающий вебхук, вызывался подсистемой PAM и был минимального размера. С одной стороны, этот подход позволяет иметь минимальное количество отказывающих компонентов. С другой, он позволяет сначала отправить, а при неудачной отправке (например, если сервера телеграм недоступны), получить ненулевой код выхода и сообщить PAM-у об этом, после чего не пустить пользователя в систему вовсе. На случай же отказа этого весьма надежного механизма вполне возможно сделать breaking glass аккаунт и ключ от него положить в сейф и никогда не доставать - это вполне стандартный подход, практикуемый массой сервисов. Все это потребует кратно меньших усилий, будет кратно надежнее функционировать и даст вам знания вечного и прекрасного (PAM), а не мимолетного (Promtail+Loki).
При этом стоит отметить, что если бы задача изначально проецировалась бы как "мне хотелось поиграться с разными модными балалайками", то цель, безусловно, оправдывала бы средства.
Хотя логин на наши сервера и запрещен по паролю, а SSH-ключи есть только у меня
Меня всегда поражала вера в то, что защита по ключу чем-то лучше, чем защита паролем. Учитывая, что ключ увести проще, чем сложный пароль из головы.
Если бы я верил в теории заговора, я бы предположил, что этот тезис придумали злые хакеры, чтобы облегчить себе жизнь.
Если бы я верил в теории заговора, я бы предположил, что этот тезис придумали злые хакеры, чтобы облегчить себе жизнь.
На самом деле не далеко от истины. ssh.com это коммерческая организация. Они за бесплатно льют энтузиастам лапшу на уши, а энтерпрайзам за деньги рассказывают как делать правильно и продают правильные батарейки. К сожалению, нынче это типовая схема монетизации опенсорс. https://info.ssh.com/why-ssh-keys-will-make-you-fail-your-audit
Ключ лучше тем, что его не получится задать простым и коротким. Поэтому подбирать ключ перебором - практически безнадёжная задача.
Конечно, можно задать очень длинный и сложный пароль. Можно настроить парольную политику, запрещающую ставить короткий и недостаточно сложный пароль. Но люди склонны совершать ошибки, и если есть возможность ошибиться - то где-нибудь рано или поздно окажется пароль 12345.
Кроме того, пароли тоже надо где-то хранить, в достаточно сложной инфраструктуре количество ключей(или заменяющих их паролей) куда выше комфортного порога запоминания несвязных последовательностей.
Пароль передается на сервер, где его могут увести, также можно перехватить локально. Учитывая что большинство людей не смотрит на отпечаток ключа сервера, здесь опять точка перехвата пароля. Приватная часть ключа не передается никуда, сам ключ можно защитить паролем и загружать в ssh-agent, есть и другие инструменты защиты ключа - аппаратный токен, который не перехватить даже локально.
В любом варианте ключ никак нельзя не перехватить со стороны сервера, он никуда не передается
Ключ всегда запаролен ещё должен быть, иначе это как-то неуютно использовать даже :)
Ещё есть интересное исследование Passive SSH Key Compromise via Lattices. Коротко говоря, условно раз на миллион можно получить из подписи полученной при рукопожатии ключик ?
Начнем с того что Вы ни разу не имеет представление о криптографии.
Производительность нынешнего железа достаточная чтобы отбрутфорсить пароль в 32 символа в приемлемое время. Врядли вы держите в голове пароль длинее 10-16 символов
Ключи в этом плане значительно более стойкие.
А аргумент в том что украсть ключь и украсть пароль не выдерживает критики. Социальная инженерия в помощь в этом плане украсть пароль даже проще чем ключ.
И потом Вам не кто не мешает установить пароль на ключ, который вы будите вводить перед каждой авторизацией по ключу.
отбрутфорсить пароль в 32 символа в приемлемое время
Приведите расчеты, приемлемое время это сколько? А стоимость?
Если возьмем простой пароль, который состоит из a–z, A–Z и 0–9, это 62 символа. 5.954 бит энтропии на символ, длина 32 символа дает 190 бит (5.954 * 32). Это 2^190 попыток (или 1.5 × 10^57). Я хотел посчитать цифры сколько это брутфорсить по времени и стоимости с текущим развитием облачного майнинга, но предварительные цифры уже были космическими и передумал дальше считать. Так про что вы?
https://wiki.realmanual.ru/ru/ssh-to-telegram
Вот еще один вариант - не стрелять из пушки по воробьям.
За ансибл ничего при колличественном вопросе не скажу, но остальное для этой задачи оверхэд
Все красиво, но непонятно!!
Особенно свербит один вопрос:
Зачем идти к проктологу, когда болит зуб!?
Вы не пробовали почитать ман на SSH??? Там есть возможность выполнять скрипт при SSH авторизации, и в окружении есть переменные кто и откуда осуществил вход.
Вся эта поделка занимает пару строк кода на птичем BASH, и еще пару строк для отправки хоть на mail, хоть на telegram, хоть в DB, куда только фантазии хватит...
Зачем бездумно тратить ресурсы, создавать кучу кода, потом всю эту поделку заливать железом...
Во-первых, статья явно учебная, демонстрирует на примере работу с Terraform, Ansible, Graphana, Promtail, Loki.
Во-вторых, далеко не каждый сервер внутри защищённого периметра имеет прямой доступ в интернет. Так что при наличии какого-то стека для мониторинга инфраструктуры логично и входы по ssh, если нужно, мониторить им же.
Вам правильно ответили, так и есть)
В первом комментарии ответил на этот вопрос: тык. Наверное я плохо высказал цели статьи и все обратили внимание на заголовок. Да, основная цель была настроить алерты после логина по SSH. Но возможно кто-то захочет отслеживать логи приложении или других файлов в системе. Можно заменить /var/log/auth.log файл на другой, тогда применимые в этой статьи инструменты, скорее всего, подойдут лучше всего.
Скажу честно, что в моих целях было получить практику по Ansible и конфигурации компонентов Grafana Loki. Исходя из этого стэка я уже решил написать статью, взяв за конечный результат то, что вы видите в заголовке :)
А ну так другое дело.
Обычно по заголовку и задача, а если есть решение проще и нет всяких ущимлений по тз, как пишет Павел выше про закрытые периметры, то народ сразу его и пишет.
Однозначно, раз учебная, тогда все координально меняет!!Но тогда нехватает дополнить сей стек несколькими аспектами.
Прикрутить следующий перечень инструментов:
syslog, zabbix, chef, gnoki, postgresql, clickhouse, fluent, Vector, postfix, kubernetes, vmware, gitlab, squid ну если что забыл, не пинайте список можно дополнить по желанию!
Но если спросят мое мнение то, любую задачу надо выполнять минимальными ресурсами. Все остальное от лукавого.
Практике по Ansible вам еще учиться и учиться, на мой личный взгляд. :) Для начала стоит осознать, что Ansible - это не запускалка баш-команд, как в вашем коде.
Ansible + Grafana Loki: Настраиваем отправку уведомлений в чат после логина на сервер по SSH