Разработчики мобильной платформы LineageOS, пришедшего на смену CyanogenMod, предупредили о выявлении следов взлома инфраструктуры проекта. Отмечается, что в 6 часов утра (MSK) 3 мая атакующему удалось получить доступ к основному серверу системы централизованного управления конфигурацией SaltStack через эксплуатацию неисправленной уязвимости. В настоящий момент идёт разбор инцидента и подробности пока недоступны. Сообщается только, что атака не затронула ключи для формирования цифровых подписей, систему сборки и исходные тексты платформы...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52872
Кто посмел!? >:(
Видимо опять безжалостные кровожадные боевики корпорастов-проприетастов.
Более правильный вопрос: нахрена кому-то понадобилось их ломать? Может просто бот, тупо перебирающий экспойты?
https://e.foundation/
Это дети тренируются. А кому ещё это нужно?
Это нужно майнерам чтобы майнить monero.
И судя по коду того же kinsing - писали совсем не дети.Ранее такое уже неоднократно проиходило с кучей других RCE:
https://www.zdnet.com/article/docker-servers-targeted-by-new.../
https://habr.com/ru/post/485300/
https://otx.alienvault.com/pulse/5c437e066b31ef12eb67bc2b
https://www.lacework.com/blog-attacks-exploiting-confluence/
https://latesthackingnews.com/2019/02/08/new-linux-backdoor-.../
https://www.auscert.org.au/blog/2018-01-05-attackers-using-r...
Это нормальная практика рулить хостами через интеренет через эти системы управления конфигурациями не овер ssh? Серьезно интересно. Просто я то на локалхосте очкую, но есть же смелые корпорации.
Вполне нормальная. При наличии авторизации и TLS ни чем не отличается от "over SSH" - в SSH точно так же могут в любой момент найти RCE. Даже VPN не дает 100% гарантий безопасности - в том же OpenVPN внезапно время от времени находят RCE.
более того - и уже успешно находили, прям сразу рут в openssh и не рут но хороший шанс вытащить годный авторизационный серт в openvpn.Поэтому никакого явного смысла в оборачивании оберток - нет. Система централизованного управления ВСЕМ - лакомый кусочек для атакующего в любом случае. А уж тем более - плохо спроектированная. А они - упс, все. Как раз salt казалась мне сравнительно разумно придуманной (в реализации я не копался, время, когда мне надо было такое, давным-давно прошло - так что не исключено что на практике там ад, трэш и п-ц).
Хз я только ссш и доверяю =) Сколько лет уже серьезных дыр не было.
> Это нормальная практика рулить хостами через интеренет через эти системы управления конфигурациями
> не овер ssh? Серьезно интересно. Просто я то на локалхосте очкую,Нет конечно, ни в коем случае. Через ssh over vpn only. Даже те серваки, что торчат в интернет.
О, заминусовали, девжопсы )
У кого-то прогорело.
и вовсе необязательно девжопсы.тебя история с heartbleed в том числе во всемилюбимом openvpn не заставила ничего такого заподозрить-насторожиться?
И это пока ты один - а когда тебя станет человек десять из разных отделов - ты изумишься, если каким-то образом узнаешь, сколько они себе понаделали джампхостов и вебшеллов в обход твоего чудовепене.
"у одного моего друга" (там не сто, а, наверное, под полтысячи если не больше человек могущих порулить теми или иными частями энтерпрайзной помойки, как впрямую, так и косвенно, выкатив какие-нибудь изменения в обход стандартных процедур) вот слуцилась - так до сих пор понять не можем, кто и откуда. Понятно что кто-то то ли свой, то ли бывший свой, слишком много знал - но совершенно непонятно ни как попал, ни что делал, ни кто это был.
Правильная система управления (правильно) торчащая наружу - имеет _меньшую_ attack surface.
Потому что прикольно, наверное, продолбать доступ, позволяющий добавить или поменять роли десятку коробок, или, даже, в модных современных реалиях, потратить кучу денег на ненужные инстансы aws - но последствия от этого чинить гораздо легче, чем последствия неведомокого залезшего к тебе в ssh и сделавшего там неведомочто.
И взламывать ее бесполезно - она не хранит ssh-ключи от всего, она просто база хост-значения.
Ну, хреновая организация конторы - это другая проблема.
И я сказал что нужно И то И другое, а всякие ансиблы и папиды, лезущие в ссш от рута, в интернете ну никак не нуждаются, а узел, который их контролирует, тоже не в другом государстве находится. Ну, если вы вместо ансибла 200 индусов из аутсосинга не наняли, конечно )
> Ну, хреновая организация конторы - это другая проблема.ну ты продолжай, продолжай мантру - что это все конторы хреново организованные, вот у тебя-то - и что тебя не поломали именно потому что ты охрененно организованный, а не потому что неуловимый джо.
> И я сказал что нужно И то И другое, а всякие ансиблы и папиды, лезущие в ссш от рута, в
> интернете ну никак не нуждаются,ну то есть продолжаешь накручивать костыли на подпорки, потому что слаще морковки не едал, и надеяться что чудо-вепеэн и сесехе тебя спасет?
Какое слово тебе непонятно в описанной мной схеме, когда в системе НЕТ вообще никакого места с ключами-от-всего - и она в нем совершенно не нуждается?
(теоретически ансибл так умеет, а для салт это основной рабочий вариант, но оба переусложнены и умеют много фатально-лишнего из-за необходимости угодить одновременно всем)
Разломали очередное недоразумение на питоне.Никогда такого не было и вот опять.
"Control and secure your digital infrastructureInfrastructure automation
Control and optimize any cloud-native or on-premises infrastructure at scaleSecurity automation
Find and fix vulnerabilities and enforce continuous complianceNetwork automation
Audit, configure, and secure your entire network from a unified platform"
Такое вот secure your entire network случилось.
Всё правильно, любое secure увеличивает attack surface.
About SaltStackSaltStack develops award-winning software used by IT and security operations teams to help modern business more efficiently secure and maintain all aspects of their digital infrastructure.
Вот и вин налицо!
Выставить CMS голой #опой в интернет? Эпик вин, чо. Безотносительно уязвимостей.
Слышал немного неприятного о salt насчёт криворукости разрабов, что пакеты ломают, не тестируют и катят в репозиторий. Была проблема с бубунтой 18 (чз кто дров наломал - мейнтейнеры убунты или каноникл). Теперь вот уязвимость.
Из альтернатив (папет, ансибл) солт казался самым здравым и простым.
>Из альтернатив (папет, ансибл) солт казался самым здравым и простым.Немного ковырял ansible, там никакие порты не должны торчать, всё через ssh.
>>Из альтернатив (папет, ансибл) солт казался самым здравым и простым.
> Немного ковырял ansible, там никакие порты не должны торчать, всё через ssh.Юзали питонсибл корпоративно. Жизнеспособно. Папид в другом месте был, тоже юзабельно, но более требователен к серверам (на больших ЛА могут быть проблемы). Это что навскидку вспомнил.
Я бы лично для себя хотел шефа завести, но тоже надо время на изучение (
Вам он может и не нужен, он в основном важен для больших количествах серверов в тысячах.
Фух, главное исходники не скомпрометированы, собираем сами себе.
Ты уверен?
Легко же проверить
как?
#тысячикрасныхглас, же. Не?
На главной странице saltstack слова security/secure встречаются 21 раз
На странице ansible - 5
chef - 4
puppet - 2
oversecured :)
Где-то я это уже видел
Как на Тео де Раадта похоже, блин :-D
Просто шикарная стратегия: дождаться появления критической уязвимости в SaltStack и эксплуатаровать её
У них там прошивок сущий мизер, в большинстве для давно устаревших устройств. Т.ч. исходники не скомпрометированы, а остальное не важно.
чем только не жертвуют, чтобы не юзать pf там, где он нужен...
О пользе стандартов ГОСТ 58412, ISO 2700x и регулярном тестировании на проникновение.
Ну вот, о критических уязвимостях объявили, а залатать забыли, ну никогда такого не было, и вот опять!
Девляпсики опять нарвались на оборотную сторону "удобства".
"Системы управления конфигурацией" нельзя внедрять так, как это делается каждым вторым девляпсом. Доступ таковой к инфраструктуре должен быть строго ограничен, причём с разделением прав.
Со всей инфраструктурой LineageOS справится один DevOps, не представляю, что там нужно разграничивать
Ну вот он и "справился", как девляпсы обычно и делают.
> Ну вот он и "справился", как девляпсы обычно и делают.Девляпсов для начала надо нанять. Когда дрочка в одиночку - это вообще другая история.
то есть если бы их было двое - они бы не нах...евертили вдвое больше дыр, are you serious?P.S. а расскажите кто-нить, вот лет пятнадцать назад, до всей этой девляпсьей муры - были у нас, помнится, такие аналоги screen+ssh - я успел начисто забыть названия всех х-ни, и, к своему удивлению, не сумел быстро найти что-то похожее поиском - ничего такого в модную-современную эпоху в живых не осталось?
То есть идея - ssh {список из сотни хостов} - открывается сотня обычных консольных сессий, с дублированием клавиатурных символов во все сразу. И возможностью видеть фидбэк (хрен с ним, вручную переключая все сто). Та хрень, что была у нас, умела при этом разные авторизации (где ключи, где не получается - переспросить не знаешь ли ты универсальный пароль от всего), но это опционально.
>то есть если бы их было двое - они бы не нах...евертили вдвое больше дырПредставь себе - нет. Возможно один из них увидел бы недостатки в коде и архитектурных предложениях другого. Это называется code review.
>То есть идея - ssh {список из сотни хостов} - открывается сотня обычных консольных сессий
Не забудь предсказать полный список комманд, засунуть в VCS, пройти review и аппрув на изменения (у тебя ведь серьезный Production, ты работаешь в команде и не хочешь его положить одной опечаткой в вызове rm, да?). Ну и не забудь что на сотне хостов могут быть разные ОС с разным окружением. И желаю удачи перепечатывать одно и то же по 100 раз (модулей у тебя ведь нет).
> Возможно один из них увидел бы недостатки в коде и архитектурных предложениях другого.Для этого опыт и знания нужны, а не петоны с докерами.
Вот только упоротое ретроградство != наличие знаний
И по суперстейбл энтерпрайз решениям уровня "открывается сотня обычных консольных сессий" это хорошо видно.
все что не пихон и докер - в глазах этих новоделанных - дремучее ретроградство.
А энтерпрайз у них - сотня систем, ага.
> Представь себе - нет. Возможно один из них увидел бы недостатки в коде и архитектурныхили не только не увидел, но и своего дерьма добавил. Это вот как раз и называется "работа в команде".
> у тебя ведь серьезный Production
нет, у меня несерьезный - не оправдывающий самостоятельное написание скриптов централизованной раздачи конфигураций (чем мы занимались еще в 2009м, когда ваших пихоноподелок еще в помине не было - кстати, взломав (как?) эту штуку - не удалось бы просто так получить ровно ничего, разьве что уронить управление - админы, не девляпсы делали).
Я вполне конкретный вопрос задал - остался ли такой софт в принципе, и как называется.
Поскольку напрочь забыл, чем мы там пользовались 15 лет назад.Твои девляпсовые страдания с опечатками в вызове rm - оставь себе, мне они неинтересны.
До 15 лет назад пользовались uucp в режиме execute, где секурностью не пахло.
Сейчас есть pssh и gnu parallel.
ну мне не очень интересно чем вы там пользовались - я вроде достаточно внятно описал задачу - параллельные сессии с визуальным фидбэком. Позволяющие хоть vi запускать.ни одна из упомянутых вами поделок и близко к той софтине не лежала и нахрен не нужны в принципе - если задача исчерпывается удаленным запуском единичной команды - я просто напишу скрипт, перебирающий хосты.
А давайте вы мне сделаете удаленный запуск команды, требующей sudo - и не в режиме nopasswd?
Я понимаю что для девляпсов это полная фантастика, у них атсосибль с рутовыми ключами от всего - только и ждет, пока эти ключи достанутся кому-то левому (впрочем, о чем это я, один у них ключ). Но такая софтина уже ж, блжад, была!
Неужели никто не вспомнит ни названия, ни современных аналогов?
clusterssh, pconsole попробуйте.
спасиб! похоже, второе и есть примерно то чем мы пользовались пятнадцать лет назад - правда, быстрое гугление приводит к неутешительному результату что уцелела только в солярисе - автор даже страницу проекта выпилил со своего сайта. (да и хрен с ним - без наших патчей оно было малопригодно, а я их не сохранил)первая вроде бы живая.
в смысле удалил? автор все на гитхаб вынес, там оно и киснет.
а, и правда, киснет (неудачное название дало пачку false positives и даже внутри самого шитхаба - а на собственно сайте автора, куда до сих пор смотрит ссылка с шитхаба - 404 без редиректа - видимо, ему стало стыдно), я с первого тыка живых ссылок не нашел, а дальше лень было.
Судя по тому что почти все правки десятилетней давности - можно не париться.(я уже не помню деталей, что там не работало или работало не так как нам хотелось, но что-то мы его много патчили в свое время. К сожалению, те патчи сгинули вместе с лавкой.)
Скорее надо на clusterssh смотреть - он вроде живой, и, помнится, я на него уже где-то натыкался, но забыл за ненадобностию. А теперь под столом завелся настоящий кластер, и тюнить все вручную несколько осточертело.
"Системы управления конфигурацией" нельзя внедрять так, как это делается каждым вторым девляпсом.
У вас есть статистика для таких утверждений? Или это личные влажные фантазии?
>Доступ таковой к инфраструктуре должен быть строго ограничен, причём с разделением прав.Ясное дело. И это все даже описано в официальной документации https://docs.saltstack.com/en/master/topics/hardening.html
В любом ПО бывают уязвимости и то что данный индивид не настроил firewall - это его личный факап к девопс-методологии не имеющий никакого отношения.
В очередной раз облажались, но методология хорошая, даа.
> В очередной раз облажалисьКто "облажались"?
Какое отношение имеет данный конкретный индивид и то что он забил на firewall к devops-методологии?
Как автоматизировать развёртывание конфигурации, так молодец, девопс. А как сервисы ставить, торчащие голой жопой в интернет - так девопс тут не виноват. Нет уж, давайте разберёмся.Во-первых, всем кто решил податься в девопс, неплохо было бы поработать для начала просто опс - поадминить ручками. А то развелось программистов, которые считают, что раз они быдлокод научились писать, то с админством справятся на раз-два. Админство - это не про автоматизацию, по большому счёту, а про ответственность. Админ может быть и тратит много времени на первоначальную настройку системы, но время и нервы бережёт за счёт того, что заблаговременно подготовился ко многим возможным проблемам - отсутствию электричества (поставил ИБП), поломкам жёстких дисков (настроил RAID-массив с избыточностью, хот-свапом и резервом в ЗиПе), настроил кластер высокой готовности, зарезервировал внешние каналы, заготовил резервные копии и инструкции по восстановлению, закрыл всё фаерволами, SELinux'ами, держит минимум программ с suid-битом, своевременно обновляет пакеты в системе и т.д. и т.п. Народная мудрость говорит, что спешка бывает нужна лишь в трёх случаях: при ловле блох, при поносе и при сношении с чужой женой.
При этом админам неплохо разбираться во внутреннем устройстве администрируемых ими сервисов, чтобы выбрать наиболее надёжные и аккуратно написанные, и при необходимости ткнуть разработчиков сервиса носом в их же фекалии, указав, как надо делать правильно (прислав по возможности готовый патч). А не тащить в свои системы всё подряд и жаловаться потом на проблемы разработчиками.
Ну и во-вторых, девопс-подход в данном случае позволяет справиться с одной сомнительной проблемой автоматизации, но позволяет себе отодвинуть на второй план множество других не иллюзорных проблем, в том числе проблему безопасности системы.
Вот в ансибле всё-таки гораздо разумнее - просто доступ через ssh, а не какой-то ещё доп.демон...
https://docs.saltstack.com/en/latest/topics/ssh/
https://docs.saltstack.com/en/latest/topics/tutorials/quicks...
Да в принципе дополнительные демоны это, даже если их голой дупой в инет не ставить, дополнительная точка отказа, а потому Ansible это правильно и хорошо, для своих целей, а Salt не нужен в принципе.
если "своя цель" - предоставить плохому парню сразу все ключи от всего и сразу с максимальными правами - то безусловно.
Уровни доступа, разграничение полномочий для разных частей конфигурирующего софта - нее, девляпс не слышал.
БОЛЬШЕ сложных ынтырпрайзных технологий
С КОТОРЫМИ ДАЖЕ ОБЕЗЬЯНА КАК ПРОСЕФИОНАЛ!!1111