Появился под Linux вирус - OrBit

Касательно ssh глупость в том, что в одном абзаце утверждается, что «вирус» практически необнаружим, а в следующем говорится, что он ssh-соединение неизвестно куда держит. Любой вменяемый админ это обнаружит моментально.

Ты говоришь, что бекконнект как-то скрывает мальварь, не требуя открывать порт на прослушку. Но суть в том, что даже если порт не открыт, левое ssh-соединение, висящее на хосте от неизвестно кого неизвестно куда - это большой красный баннер «Что-то не так! Нас взломали!» Так что глубоко параллельно, с какой стороны будет инициализирован ssh-коннект.

Но суть в том, что даже если порт не открыт, левое ssh-соединение, висящее на хосте от неизвестно кого неизвестно куда - это большой красный баннер «Что-то не так! Нас взломали!»

как ты найдешь и поймешь, что это «левое» соединение?

Касательно ssh глупость в том, что в одном абзаце утверждается, что «вирус» практически необнаружим, а в следующем говорится, что он ssh-соединение неизвестно куда держит. Любой вменяемый админ это обнаружит моментально.

если до этого поднят ssh, как ты моментально обнаружишь?

Как чуть вниз рисуешь сразу тут начинается бугурт по подводу анатомии. Что слишком пошло (но это пони). Тем более один модератор с пунктиком есть (гиппофоб видать). А извращенец в итоге всё равно я.

А второе ухо — примерно рассчитываешь, что прикроется гривой 🤷‍♂️

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

netstat -an|awk '/^tcp/{++S[$NF]}END{for(a in S) print a,S[a]}'

Потому пойдём по исходящим и так далее.

Разумеется, это выполняется в темплейте мониторинга с определённой периодичностью, складывается в логи, рисует графики и шлёт алерты при указанных значениях.

как ты узнаешь, что это ssh соединение? тем более - исходящее?

наверное по-глупости люди ставят недешевые чекпоинты с фортиками и польтами, разбирают юзерский хттпс трафик, прогоняя файлы через антивирусы с песочницами, даже до белых списков доходят некоторые

а тут - хуйнул нетстат - и дело в шляпе:)

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

tcpdump -ni ens3 'tcp[(tcp[12]>>2):4] = 0x5353482D'

наверное по-глупости люди ставят недешевые чекпоинты

Это ещё один уровень защиты, не отменяющий остальные. Обсуждаемый в статье «вирус» вычисляется проще.

Чекпоинты не бесполезны, но подход напоминает «наденьте третий презерватив...». Белые списки, сегментация сети - почему нет? Это зачастую бесплатно или очень дёшево.

ухты, киньте ссылку на гит, хочу собрать и попробовать заразиться

А так оставляешь ssh по белому ip с логином root и пустым паролем и ждёшь

Это не «сломать защиту». Это просто диверсия со стороны админа.

Максимально допустимое разрешение 300х300. Либо разрешения не хватит, либо на крупном мониторе будет мелко (а при масштабировании картинки всплывет мыло). Но у него «комплектные пони» тоже были.

Много где можно. Вроде даже в убунте раньше создание обычного пользователя не было обязательным.

Разумеется, это выполняется в темплейте мониторинга с определённой периодичностью, складывается в логи, рисует графики и шлёт алерты при указанных значениях.

Это всё, конечно же, полная розовоочковая херь от админа двух впсок. Никто не будет на тысячи линупсов натягивать мониторинги исходящих соединений и следить за этим. Для этого существуют МСЭ, сетевая изоляция и вычислительные контуры. Но админам впсок не рассказывают, что в 2022 так люди живут.

извращенец в итоге всё равно я

Конечно, уже на жирафов переходишь, с такой-то шеей…

рудом поддаётся обнаружению при сканировании антивирусным ПО
изменяя переменную среды LD_PRELOAD

Мне казалось, что LD_PRELOAD - это самый тупой и легко-обнаружаемый вид руткита.

Ну на Windows — это диверсии со стороны пользователя.

Как скажешь, админ трёх впсок. А у меня на работе мониторинги натягиваются автоматом при разворачивании систем из подготовленных шаблонов. Что не отменяет сетевой изоляции и прочего. У нас ещё и selinux включён в строгом режиме на всех десятках тысяч хостов(как железных, так и виртуальных), а отдельная команда следит за политиками. И ядра везде самосборные, с уклоном как в производительность(например, очереди обработки в сетевой части), так и в безопасность. И прочие ненужные вещи делаются даже в 2022-ом году. Так что админь свои три впски спокойно и не беспокойся.

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

Знаешь, я таких историй за 20 лет столько наслушался про самосборные ядра и 100% покрытие мониторинга на миллиарде хостов... А как начнёшь выяснять всё схлопывается до офисного сервера печати))

чем твои серверы занимаются? я так понял, они не публичные?

Я узнаю, что у меня есть больше исходящих коннектов неизвестно куда и неизвестно от кого, чем требуется.

что значит «больше»,число соединений константно что ли?

ну, и вообще, серверы наружу проходят, по любым портам?

Как скажешь. Дело твоё. )

Я, кстати, не знаю, как в 2022-ом настраивается сервер печати - офисной сеткой и серверами отдельная команда занимается.

Разные серверы разными задачами. В общем случае:

балансировщик нагрузки -> 
  проксирующие фронт-серверы -> 
    бек-серверы -> 
    обработчики данных ->
      серверы хранения данных.

Непосредственно принимает запросы снаружи только балансиры. Фронты принимают запросы только от них, но отдают контент напрямую пользователю. Остальные серверы с внешним миром не общаются вообще. Все эти серверы в принципе не инициируют самостоятельных коннектов наружу. Есть группы отдельных сервисов, которые общаются с внешним миром и могут инициировать коннекты - у них свои политики мониторинга, разумеется, в своей сетевой подгруппе.

Это если очень упрощённо.

Все эти серверы в принципе не инициируют самостоятельных коннектов наружу.

днс запрос наружу пройдёт?

Нет, конечно. DNS-запросы у меня даже домашние компы наружу не могут сделать. А на работе там ещё сложнее. Там внутренняя довольно хитрая система DNS.

зачем тогда это было писать?

Я узнаю, что у меня есть больше исходящих коннектов неизвестно куда и неизвестно от кого, чем требуется.

если выход наружу закрыт? или не закрыт?

Есть группы серверов, где не закрыт и/или открыт частично. Я же с самого начала написал, что при настройке мониторинга используются групповые политики.

Есть группы серверов, где не закрыт и/или открыт частично.

значит открыт где-то, так?

и сетевую активность ты контролируешь мониторингом?

В том числе и мониторингом. Я не могу понять, что ты хочешь доказать? Что мониторинг не нужен и ничего не может найти?

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

Я привёл тебе одну из команд нетстата, которая серди прочих используется в шаблонах мониторинга для сбора информации. Есть статистика по iptables, есть данные с железных маршрутизаторов, забираемые по snmp и т.д. Всё это собирается в общую базу, которая уже и является источником данных для анализа.

В самом простейшем случае - хосту разрешено n одновременных ESTABLISHED коннектов наружу и/или n SYN-коннектов в определённый период. Всё, что выше n - Alert. Это самые простые. Но не только. В отдельных случаях правила ужесточаются. Вплоть до сбора статистики по продолжительности коннекта(но это редкость, насколько я знаю - надо у сетевиков уточнить, это они такое добавляли). Помимо количественной информации, есть логические анализаторы, которые смотрят в логи со всей полученной выше инфой(логи не только для мониторинга используются, так что излишним сбор данных не является).

Собирать как обычно руками? И кстати где ссылка на сурсы?

В самом простейшем случае - хосту разрешено n одновременных ESTABLISHED коннектов наружу

А зачем это, если в разрыв периметра ставится МСЭ и политики нарезаются централизованно?

Всё, что выше n - Alert.

Шок, админ решил сделать fping и переполошил всю первую линию... читать далее.

Что за мониторинг-то?

В самом простейшем случае - хосту разрешено n одновременных ESTABLISHED коннектов наружу

а если стало n-1, а потом опять n - то всё хорошо?

чёт мне надоело уже…

Что никто в здравом уме в большой гетерогенной инфраструктуре не будет мониторить каждый идиотский хост на количество внешних коннектов. Для это существуют совсем другие решения на базе SOC, не требующие оравы инженеров мониторинга, дежурных и админов.

А зачем это, если в разрыв периметра ставится МСЭ и политики нарезаются централизованно?

Выше я уже писал. Наличие одного контура защиты не отменяет другой.

Шок, админ решил сделать fping и перепрошил всю первую линию... читать далее.

Админ не будет без предупреждения о проведении работ делать даже fping с прод-серверов.

Что за мониторинг-то?

Zabbix с очень кастомными шаблонами и модулями, ELK+логика обработки, grafana, самописные системы и остатки от cacti(надеюсь, скоро уйдёт... лет через несколько :) ).

Дежурный админ увидел Alert, проанализировал ситуацию, закрыл его если всё нормально или эскалировал, если если подозрение на ненормальное поведение.

еще раз, на серверах смотрящих наружу, количество соединений константно?

Оравы инженеров мониторинга нет. Правила мониторинга разные команды добавляют самостоятельно в общую систему. Дежурные админы нужны всегда. И смотрят они не только за коннектами. Я рад, что у вас в компании удалось всё полностью автоматизировать и люди больше не нужны. Слава роботам!

Наличие одного контура защиты не отменяет другой

Да, но высокоуровневые контуры должны упрощять низлежащие, а не усложнять. Если есть дорогущий МСЭ и специальные люди из devsecops, то зачем поддерживать лапшу из скриптов на каждом балансировщике? Чтобы что? Затраты бюджета обосновать бизапасностью?

Zabbix с очень кастомными шаблонами и модулями, ELK+логика обработки, grafana, самописные системы и остатки от cacti(надеюсь, скоро уйдёт... лет через несколько :) ).

Zabbix просто сдохнет на жалкой тыще хостов с такими кастомными шаблонами, ну или поддерживать его будет сущий ад. Сколько хостов то?

К полету к проксиме центавра тоже

нет абсолютно никакой трудности, кроме времени и денег.

Ну пока что я вижу, что если всё это правда, то у вас театр безопасности, а не архитектура. Хотя в каком-нибудь Сбере вполне может быть так.

Ещё раз. Зависит от серверов. На смотрящих наружу фронтах, например, количество произвольных инициированных сервером соединений равно нулю, например. На почтовых серверах, например, есть пороговые значения, очень высокие, но стоят алерты на количество одновременных коннектов и запросов на сорединение(если висит сразу много, что-то идёт не так). Данные о количестве выставляются на основе статистики, корректируются в процессе работы после анализа. Это некоторые примеры.

то зачем поддерживать лапшу из скриптов на каждом балансировщике?

Лапши из скриптов на каждом балансировщике нет. Где я про такое говорил?

Zabbix просто сдохнет на жалкой тыще хостов с такими кастомными шаблонами, ну или поддерживать его будет сущий ад. Сколько хостов то?

Zabbix не единственная система мониторинга, о чём я уже писал. И не дохнет. Шаблоны под разные группы хостов разные - общие только как везде для сборки данных по железу, типовые проверки ОС и тому подобный «почти» стандарт. Почти, потому что, например, все железные серверы однотипные и лишние проверки из шаблонов исключены. На данный момент около 10к железных хостов в трёх датацентрах. Разумеется, сервер мониторинга не один. Но в итоге данные таки сливаются в общую базу, анализом которой занимается уже не заббикс.

На почтовых серверах, например, есть пороговые значения, очень высокие, но стоят алерты на количество одновременных коннектов и запросов на сорединение(если висит сразу много, что-то идёт не так).

вот, и на этом почтовом сервере появляется одно соединение на 25 порт, но по ssh

что и как будет происходить?

Иначе завтра за пределами ЛОРа будут говорить, что Linux изобрели Перун, Ярило и Сварог.

Но в этом случае мы уж точно будем знать, что ветер дует из Бердянска :)

Если выключить все другие проверки, анализатор увидит долго висящий коннект непонятно от кого(не от почтового сервера). Выскочит варнинг у дежурного админа. Далее по ситуации. На почтовом сервере количественные проверки нужны для отлова потенциальных ошибок в почтовой подсистеме и необходимости массовой отправки/переотправки сообщение. Количественные проверки больше нужны на хостах, где нет такого большого разрешённого колличества соединений.

Скажи честно, ты уже прекрасно понял, как всё работает, а вопросы задаёшь исключительно, чтобы оставить за собой последнее слово. Мне уже становится скучно. Надо допивать кофе и идти посмотреть, что там в джире мне написали и начинать админить две свои впски.

Скажи честно, ты уже прекрасно понял, как всё работает, а вопросы задаёшь исключительно, чтобы оставить за собой последнее слово

отнюдь, первоначальные ответы звучали наивно, пришлось вытягивать

Если он крадёт данные, то очевидно для отправки их куда-то по сети, а значит, этот момент можно зафиксировать и сдампить траффик.

Для отправки можно использовать какой-нибудь ботнет, что затруднит обнаружение только по трафику.

Как подцепить вирус на Linux понятия не имею,может кто научит?

Легко.
Способ проще, но ждать дольше.
1. Подключаем белый ip
2. Открываем (если закрыт) ssh
3. Разрешаем в ssh root логин
4. Меняем рутовый пароль на что-то типа 12345678
5. Profit
Способ чуть сложнее, но есть надежда что сработает быстрее
Всё тоже самое как и в первом, только добавляем ещё пользователей
anna,pit,user и т.п. с тем же паролем. Добавляем этих пользователей в группу sudo.