Известная немецкая хостинговая компания Hetzner обнаружила (https://pay.reddit.com/r/netsec/comments/1fsuqm/hetzner_tech.../) взлом своих систем и зафиксировала (http://wiki.hetzner.de/index.php/Security_Issue/en) размещение весьма труднообнаружимых бэкдоров на своих серверах. Взлом инфраструктуры был произведен с использованием руткита, обнаруженного инженерами компании во внутренней системе мониторинга, использующей Nagios (разработчики Nagios утверждают (http://www.mentby.com/Group/nagios-users/nagios-backdoor.html), что в Hetzner используется форк проекта - Icinga (https://www.icinga.org/)). В результате взлома атакующие потенциально могли получить доступ ко всем данным клиентов, указанным в панели управления, в том числе к хэшам паролей и информации о совершённых платежах.
Наиболее интересным моментом данной атаки является тот факт, что Rootkit поражает процессы Apache и sshd только в оперативной памяти. Файлы, хранящиеся на диске модификации не подвергаются, что делает невозможным обнаружение подобного типа вредоносного ПО средствами поиска руткитов типа rkhunter или путем сверки контрольных сумм файлов. Кроме того, процессы поражаются на лету и после модификации не перезапускаются, что дополнительно усложняет обнаружение подобной атаки. Отмечается, также то, что в рутките присутствовали функции для манипуляции ProFTPD.
В уведомлении (http://pastie.org/8015553), отправленном клиентам, компания отмечает, что пароли хранились с использованием SHA256 и солью, поэтому их подбор затруднён, тем не менее, несмотря на это, клиентам рекомендуется сменить пароли. Кроме того, утверждается, что данные кредитных карт скорее всего не пострадали, так как полный серийный номер карт не хранится на серверах компании, а хранятся только последние 3 цифры, а для взаимодействия с серверами платежной системы используется привязанный к карте случайный номер.URL: http://www.heise.de/newsticker/meldung/Hetzner-gehackt-Kunde...
Новость: http://www.opennet.ru/opennews/art.shtml?num=37116
Очень красивое письмо прислали. Сразу видно, как ребята работают над проблемами. Заодно слегка пролили свет на то, как всё устроено. Красота!
Немцы. Педантично раскурили как их поломали, обнаружили весьма нетривиальную пакость (in-memory хак процессов - по сути высший пилотаж у хакеров), честно написали WTF. Вот все бы так.
> in-memory хак процессов — по сути высший пилотаж у хакеровой, да ладно. dynamic binary instrumentation — это обычная техника. никакого «высшего пилотажа» она не требует, просто внимательности и аккуратности. другое дело, что современные скрипткиддисы и в «приветмире» получают 17 ошибок и 34 ворнинга…
> ой, да ладно. dynamic binary instrumentation — это обычная техника. никакого «высшего
> пилотажа» она не требует, просто внимательности и аккуратности.Так вот это и является по сути высшим пилотажем. Большая часть подобных господ нынче работает грубо и топорно. А чтобы так аккуратненько сработано, чтоб только в памяти и больше вообще нигде - такие экспонаты чуть ли не по пальцам пересчитать можно.
> другое дело, что современные скрипткиддисы и в «приветмире» получают 17
> ошибок и 34 ворнинга…Ну так о том и спич.
>Ну так о том и спич.What did you say?
> What did you say?Get off, script-kiddie.
Немцы в плане хостинга вообще молодцы! Пользуюсь шнайдер-хост, ДЦ немецкие - пинг маленький (это при том что ДЦ бюджетные) и ап тайм 99.9%
Ну и какая операционка там используется?Явно здесь linux виноват.Уже много
свидетельств о проломах в linux серверах, может,всё таки рано хоронят *bsd системы?И на более ответственные машины ставить их?
> Ну и какая операционка там используется?Явно здесь linux виноват.И в чем именно состоит вина именно Linux? В том что он честно выполнял программы, в том числе и систему мониторинга с бэкдором? :)
> И на более ответственные машины ставить их?
Лучше minix какой-нибудь. Прикидываться неуловмым Джо - так по полной.
>> Ну и какая операционка там используется?Явно здесь linux виноват.
> И в чем именно состоит вина именно Linux? В том что он
> честно выполнял программы, в том числе и систему мониторинга с бэкдором?
> :)
>> И на более ответственные машины ставить их?
> Лучше minix какой-нибудь. Прикидываться неуловмым Джо - так по полной.От рута запускается скрипт, запускающий демон, который запускается не от рута.
То, что процесс(бекдор в системе мониторинга), работающий не от рута, смог получить привилегии рута, для просмотра всех файлов, воздействия на сегменты данных и кода других процессов, говорит о том, что он и/или работает от рута,работает на уровне ядра.В любом случае получить такие возможности в запускаемом не от рута процессе можно только через средство повышения привилегий,желательно,через уязвимость в ядре, чем прославился именно Linux.
Сам придумал шняжку?
Кстати на ответственных участках того же самого РЖД/ЭмВеДе/ФеСеБе в последние годы стали закупать вразы меньше специализированных железок от всяки кисок ибмов хпишек
> Кстати на ответственных участках того же самого РЖД/ЭмВеДе/ФеСеБе в последние годы стали
> закупать вразы меньше специализированных железок от всяки кисок ибмов хпишекТакие железки покупаются раз и надолго, не берут новые ещё не значит, что берут x86+всяко
разно.Или кто-то туда из инсайда тут тусуется?
>> Кстати на ответственных участках того же самого РЖД/ЭмВеДе/ФеСеБе в последние годы стали
>> закупать вразы меньше специализированных железок от всяки кисок ибмов хпишек
> Такие железки покупаются раз и надолго, не берут новые ещё не значит,
> что берут x86+всяко
> разно.Я вам скажу даже больше чем вы не то что знаете а даже и не предполагаете
- Еще года 4 назад на ответственных участках стали выводить из работы ваши любимые киски и тому подобную хреноину
а выводить в том плане что отключать и ложить на полочку
Вот и получается один раз купил и больше не покупают так как этой хреноиной все полки забиты и домой нельзя забрать так как на балансе числитсяP.S. И как вы думаете и чем же всетаки заменили киски ибмы и хпшники ???
> P.S. И как вы думаете и чем же всетаки заменили киски ибмы
> и хпшники ???писарями, курьерами и почтовыми голубями?
Ямщики и RFC1149... ммм... винтажненько :)
> P.S. И как вы думаете и чем же всетаки заменили киски ибмы
> и хпшники ???Старыми Sun box на OpenBSD?Не правда заинтриговали.Вдрызг перепиленными отечественными
сборками Linux плюс тазики с intel iX?Чем можно заменить циски с их главным преимуществом
в большом количестве сетевых интерфейсов на борту?Как числятся вновь приобретаемые машины
на балансе, при не списанных старых?
> - Еще года 4 назад на ответственных участках стали выводить из работы
> ваши любимые киски и тому подобную хреноинуЭто после югов?
> не используют такие прогрессивные, открытые, бесплатные, развитые системы вроде linux/bsd,А кто вам это сказал? Вы например поинтересуйтесь кто SELinux больше всего хотел. Для соответствия регламенту, так сказать.
> Изначально говорилось о большей дырявости linux, по сравнению
> с другими unix-like ос.Дайте пример уязвимости в ядрах *BSD, illumos/solaris, позволяющие
> повышение привилегий за последние два года?Тут ответ будет очень даже простым
В ядра системы BSD не пихают все подряд в отличии от Linux
вот только по этой причине кому нужна безопасность и тот кто понимает в безопасности используют именно BSD системы
> Тут ответ будет очень даже простым
> В ядра системы BSD не пихают все подряд в отличии от Linux
> вот только по этой причине кому нужна безопасность и тот кто понимает
> в безопасности используют именно BSD системыВообще спорно, в linux пихают много, но пихают известные комерческие шараги для поддержки чего-то своего, и с различным рвением они занимаются поддержкой по своему коду платной/бесплатной.В случае с BSD код пишут и поддерживают какие-то левые мэны про которых только мыло известно, да всякие посты на разных сайтиках, так что тоже стрёмно.
> В случае с BSD код пишут и поддерживают какие-то левые мэны
> про которых только мыло известно, да всякие посты на разных сайтикахВ случае NetBSD известны паспортные данные *каждого* коммитера,
так что в случае злонамеренного вредительства тебя быстро
найдут и посадят на кол. А вот в Линуксе как раз ровно так, как
ты описал -- левые мэны-анонимы. На мой взгляд это как раз ни о чем особо
не говорит, но раз уж вы тут ЭТО выдвигаете за аргумент...
> так что в случае злонамеренного вредительства тебя быстро найдут и посадят на кол.Осталось всего ничего - обнаружить злонамеренное вредительство и доказать что это не ошибка а специально так. Помнится, в лине однажды как раз пытались закосить под именно безобидную опечатку (= вместо == в условии), но это было безжалостно запалено.
> Тут ответ будет очень даже простымЕще проще: неуловимый Джо нафиг никому не уперся. Много вы серверов с illumos видели? Да и бзди вон уже даже яха с апачом повыбросили, а менее стойкие сделали это еще раньше. А ломать то что фиг найдешь хакерам не интересно: размер морковки-заманухи должен согласоваться с размером возни.
>> Тут ответ будет очень даже простым
> Еще проще: неуловимый Джо нафиг никому не уперся. Много вы серверов с
> illumos видели? Да и бзди вон уже даже яха с апачом
> повыбросили, а менее стойкие сделали это еще раньше. А ломать то
> что фиг найдешь хакерам не интересно: размер морковки-заманухи должен согласоваться с
> размером возни.На Illumos построен joyent, крупный хостинг.То есть примеры хоть единичные, но есть,
три очень крупных хостинга из рейтинга netcraft на freebsd, и указанные проекты не меньше чем hetzner.
Если нашлись ломать hetzner, то почему бы не ломать joyent или кого-то из тех, кто
на BSD?Но примеров тому нет.Думается, что это не случайно.
> три очень крупных хостинга из рейтинга netcraft на freebsd, и указанные проекты
> не меньше чем hetzner.
> Если нашлись ломать hetzner, то почему бы не ломать joyent или кого-то
> из тех, кто
> на BSD?Но примеров тому нет.Думается, что это не случайно.Как не обидно будет сказанно но и до них добирутся
так как работнички в хостинг компаниях оставляют желать лучшего
Хостинг это вообще ну очень уязвимое место и любые хостинги как ломали так и будут ломать
Меньше шансов быть похеканным у маленьких хостинг компаний
Шаред помойки вообще ломают регулярно. Наверное они настолько к этому привыкли что не считают нужным это анонсировать уже. Размещение сайта на шареде подразумевает довольно высокий риск его комппрометации, чисто в силу технологий организации шареда.
> На Illumos построен joyent, крупный хостинг.То есть примеры хоть единичные, но есть,Единичные примеры хакеров не очень интересуют. Возни много а профита - не очень. Вот и возникает подозрение на неуловимого Джо. В том плане что у саней код в плане качества - самый обычный, тезис о том что его качество на голову выше других (например, тех кто пишет пингвин) - надо как минимум доказать. Хотя-бы прогнав анализатор типа coverity на сорце и сравним число проблем на единицу объема кода. А поскольку этого ессно не сделано - это все обычное блаблабла. Насколько я знаю, у пингвина в целом с качеством кода все довольно хорошо и там качество выше чем в среднем по отрасли.
> три очень крупных хостинга из рейтинга netcraft на freebsd,Цифры приводимые неткрафтом в основном показывают "кто больше неактивных сайтов у себя на шареде понастрогал". А где у них, собственно, оценка размеров хостинга? Ну там число серверов, например? Или какой-то иной вменяемый критерий.
> и указанные проекты не меньше чем hetzner.
Как бы никто не писал этот бэкдор лично под hetzner как вы понимаете. Это скорее всего какой-то типовой универсальный бэкдор на который они по недосмотру нарвались.
> Если нашлись ломать hetzner, то почему бы не ломать joyent или кого-то
> из тех, кто на BSD?Но примеров тому нет.Думается, что это не случайно.Потому что кастомная атака под кого-то конкретного - совсем не то же самое что просто ситуация "упс, мы облажались и версия софта с бэкдором утащила нашу инфраструктуру в ботнет".
Ага, например в ядра BSD не пихают Lua. oh wait...
> Ага, например в ядра BSD не пихают Lua. oh wait...Это лучше, чем писать нетребовательную к скорости бытовуху на "С"
и иметь то, что мы имеем -- эксплойт на эксплойте, дыру на дыре,
rootkit на rootkit-е.
> и иметь то, что мы имеем -- эксплойт на эксплойте, дыру на дыре,Пыхописты, питонисты, жабисты и кто там еще постоянно наезжали на си. А вместе с тем, дырявая вебня на данный момент является основным вектором взлома серверов. И писана она совсем ни разу не на сях.
Именно классические эксплойты сетевых сервисов путем переполнений нынче явно не самый злободневный топик. А само линевое ядро btw я уж и не помню когда по сетке ремотно кто-то взламывал. Легенды говорят что когда-то вроде было. Но я даже не помню когда. В ближайшие лет 5 вроде не было таких прецедентов.
> rootkit на rootkit-е.
Не вижу как наличие или отсутствие в ядре lua мешает жить руткитам. Бред сивой кобылы в лунную ночь. Тот же lua в лине можно и в юзермоде запустить, если уж он нужен. А как вы сказали - скорость не критична, так что в юзермоде вполне нормально. Нафиг оно в кернеле?
> с другими unix-like ос.Дайте пример уязвимости в ядрах *BSD, illumos/solaris,Да, трупы мало кто исследует. Один раз вскрыли в морге - и на кладбище. А детально изучать все гастриты и простуды у трупов мало кто захочет.
> Дайте пример уязвимости в ядрах *BSD,Насчет ядер не скажу, а вот сервак у фрибздунов компрометировали чуть ли не в этом году аж.
> В любом случае получить такие возможности в запускаемом не от рута процессе можно только
> через средство повышения привилегий,желательно,через уязвимость в ядре, чем прославился
> именно Linux.Категорично. Но неверно. Есть и другие пути запустить код в ядре. Например, через панель управления VPS.
Если сервера инфицировались по сетке с каждым перезапуском, то достаточно отмониторить трафик при помощи любого снифера, чтобы выяснить как и когда проходит инфекция. Если же это не сделано, значит либо немцы -- дубы, либо всё же был использован другой путь.
> Категорично. Но неверно. Есть и другие пути запустить код в ядре.Да есть,но первый самый прямой и не зависящий от особенностей архитектуры проекта, которую
в других вариантах надо знать в деталях.
>> Категорично. Но неверно. Есть и другие пути запустить код в ядре.
> Да есть,но первый самый прямой и не зависящий от особенностей архитектуры проекта,
> которую
> в других вариантах надо знать в деталях.Поясните вашу мысль, пжлста. Что вы подразумеваете под архитектурой? Чтобы написать эксплойт эксплуатирующий что-нибудь типа переполнения стека, впихнуть таким образом в ядро пару килобайт кода, и потом методом раскрутки создать в ядерном пространстве некий "гипервизор", который позволит уже внедрять код в выбранные процессы -- для этого потребуется знание архитектуры. Очень серьёзное знание архитектуры. И в то же время использование софта гипервизора может весьма сгладить эти тонкости. Вплоть до того, что управляющая часть руткита будет написана на java и не полагаться ни на какие особенности архитектуры, поскольку они будут сглажены джавовскими же API предоставленными гипервизором.
> Поясните вашу мысль, пжлста. Что вы подразумеваете под архитектурой? Чтобы написать эксплойт
> эксплуатирующий что-нибудь типа переполнения стека, впихнуть таким образом в ядро пару
> килобайт кода, и потом методом раскрутки создать в ядерном пространстве некий
> "гипервизор", который позволит уже внедрять код в выбранные процессы -- для
> этого потребуется знание архитектуры. Очень серьёзное знание архитектуры. И в то
> же время использование софта гипервизора может весьма сгладить эти тонкости. Вплоть
> до того, что управляющая часть руткита будет написана на java и
> не полагаться ни на какие особенности архитектуры, поскольку они будут сглажены
> джавовскими же API предоставленными гипервизором.Найти переполняющийся стек в linux задача не слишком тривиальная.Если пропихнули прогу с
бекдором, то и вообще не требующаяся, первое, что должен сделать руткит, получить полный доступ к системе, обеспечивается другими возможностями, в самом linux, благо, имеющимися.
http://www.opennet.ru/opennews/art.shtml?num=36933
> Найти переполняющийся стек в linux задача не слишком тривиальная.статических анализаторов уже далеко более одного. Это сильно упрощает задачу.
>> Найти переполняющийся стек в linux задача не слишком тривиальная.
> статических анализаторов уже далеко более одного. Это сильно упрощает задачу.В linux сейчас параметры функций передаются через регистры, а не через стек, там, где используется стек контроль начинается ещё с gcc.Плюс
на анализаторы особо не стоит надеятся.
> статических анализаторов уже далеко более одного. Это сильно упрощает задачу.Ага, только и защит от переполнения стека понагородили. Плюс на современных архитектурах ABI таково что параметры как уже метко заметил один гражданин не в стеке а в регистрах, что дополнительно усложняет это начинание.
>[оверквотинг удален]
>> же время использование софта гипервизора может весьма сгладить эти тонкости. Вплоть
>> до того, что управляющая часть руткита будет написана на java и
>> не полагаться ни на какие особенности архитектуры, поскольку они будут сглажены
>> джавовскими же API предоставленными гипервизором.
> Найти переполняющийся стек в linux задача не слишком тривиальная.Если пропихнули прогу
> с
> бекдором, то и вообще не требующаяся, первое, что должен сделать руткит, получить
> полный доступ к системе, обеспечивается другими возможностями, в самом linux, благо,
> имеющимися.
> http://www.opennet.ru/opennews/art.shtml?num=36933Ну, и? Если мы заглянем в код, увидим массу телодвижений специфичных для линукса и для x86_64. Понимая при этом, что сей баг не более чем local-root, надо понимать также и то, что понадобится ещё некоторое количество специфичных для платформы багов для получения шелла. Сплошная зависимость от платформы, и весьма неприятная. Тем более что сервера периодически апдейтят ПО обнуляя возможность использования багов.
Так что, ваши утверждения о том, что ломать систему изнутри проще, чем снаружи через гипервизор, выглядят как минимум весьма сомнительными. А я бы сказал, просто неверными и притянутыми за уши.
> Ну, и? Если мы заглянем в код, увидим массу телодвижений специфичных для
> линукса и для x86_64. Понимая при этом, что сей баг не
> более чем local-root, надо понимать также и то, что понадобится ещё
> некоторое количество специфичных для платформы багов для получения шелла. Сплошная зависимость
> от платформы, и весьма неприятная.С самого начала в треде обвинялся именно linux, в предположении заточенности используемого для взлома механизма именно под него.
Тем более что сервера периодически апдейтят
> ПО обнуляя возможность использования багов.
> Так что, ваши утверждения о том, что ломать систему изнутри проще, чем
> снаружи через гипервизор, выглядят как минимум весьма сомнительными. А я бы
> сказал, просто неверными и притянутыми за уши.Упомянутая уязвимость просуществовала два года, и затронула широкий спектр версий ядра.
Сколько бекдоров могли за это время проломиться в инфраструктурах?
>> Ну, и? Если мы заглянем в код, увидим массу телодвижений специфичных для
>> линукса и для x86_64. Понимая при этом, что сей баг не
>> более чем local-root, надо понимать также и то, что понадобится ещё
>> некоторое количество специфичных для платформы багов для получения шелла. Сплошная зависимость
>> от платформы, и весьма неприятная.
> С самого начала в треде обвинялся именно linux, в предположении заточенности используемогоЕстественно заточенность на конкретную target-систему будет иметь место быть. Даже если всё делается через панель управления vps. Но заточенность, при некоторой ловкости рук, сведётся к двум версиям payload'а: x86 и x86_64. Без необходимости под каждое ядро компилять специализированный бинарь. Что, кстати, на практике (в которой для взлома системы используется, подчастую, цепочка уязвимостей в разных программах) может вылиться в нехилую такую гору бинарей под разные версии этих разных программ. А если ещё учесть, что разные версии программ могут иметь разные уязвимости, и цепочки уязвимостей на разных системах могут быть совсем разными, то... Тут уже к каждому серверу потребуется индивидуальный подход. Оно за два года можно, конечно, но... хз-хз... сомневает.
> для взлома механизма именно под него.
> Тем более что сервера периодически апдейтят
>> ПО обнуляя возможность использования багов.
>> Так что, ваши утверждения о том, что ломать систему изнутри проще, чем
>> снаружи через гипервизор, выглядят как минимум весьма сомнительными. А я бы
>> сказал, просто неверными и притянутыми за уши.
> Упомянутая уязвимость просуществовала два года, и затронула широкий спектр версий ядра.Лишний аргумент в пользу уязвимости панели управления vps, а не в target-системе.
> Сколько бекдоров могли за это время проломиться в инфраструктурах?
Я не Б-г, я не могу ответить на этот вопрос со сколь-нибудь приемлимой точностью. Ответ "дохрена" Вас устроит?
> С самого начала в треде обвинялся именно linux,При том - на основе каких-то вымыслов обвинителя, не основанных на каких либо фактах.
Slysh bratuha a v kakom torgovom zale to rabotaesh, ty skazhi, mozhet ya pridu, kuplyu u tebya chego-nibud', zaodno i obsudim problemu..
> уязвимость в ядре, чем прославился именно Linux.Скорее, в линухе просто стали искать, благодаря достаточной популярности. А остальные - ну вон в винде недавно как раз нашли. А неуловимые Джо на то и неуловимые, чтобы их никто не ловил.
windows головного мозга ? Причём тут linux\bsd и т.п., когда речь про уязвимость в системе мониторинга (то бишь в приложении) ?
> windows головного мозга ? Причём тут linux\bsd и т.п., когда речь про
> уязвимость в системе мониторинга (то бишь в приложении) ?Смотрите #27
> Смотрите #27Я не вижу там никаких обоснований почему *bsd сами по себе будут безопаснее. Как известно, неуловимый Джо неуловим только до тех пор пока его никто не ловит.
>> Смотрите #27
> Я не вижу там никаких обоснований почему *bsd сами по себе будут
> безопаснее. Как известно, неуловимый Джо неуловим только до тех пор пока
> его никто не ловит.Примеры "больших" взломов проектов на BSD в студию, а такие ещё остались.
> Примеры "больших" взломов проектов на BSD в студию,Да вон фрибсдшники недавно как раз серваки у себя тушили. По причине взлома.
> а такие ещё остались.
Уже очень мало. Даже яху и апач сервера на линь переводят нынче. Ясен перец фокус внимания при таком раскладе сместится в сторону линя.
Тем не менее, я нигде вообще не вижу упоминания ядерных уязвимостей кроме вашей фантазии. То-есть, я допускаю что в теории они могут быть. На практике - где вообще пруф что ими пользовались, а не использовали какие-то еще методы?
> Да вон фрибсдшники недавно как раз серваки у себя тушили. По причине
> взлома.Там был проё* ssh аккаунтов.Никаких взломов.
> Там был проё* ssh аккаунтов.Никаких взломов.Ну так предустановленный в программе бэкдор тоже по большому счету не взлом ОС. А то этак запуск rm тоже можно взломом назвать.
всё ломают, справедливости ради и kernel.org ломали -- http://www.opennet.ru/opennews/art.shtml?num=31651
> всё ломают, справедливости ради и kernel.org ломалиТак с этим никто и не спорит...
> Примеры "больших" взломов проектов на BSD в студию, а такие ещё остались.Кх-кх.. а можно вообще пример "больших" проектов на BSD?:)
>> Примеры "больших" взломов проектов на BSD в студию, а такие ещё остались.
> Кх-кх.. а можно вообще пример "больших" проектов на BSD?:)
>>> Примеры "больших" взломов проектов на BSD в студию, а такие ещё остались.
>> Кх-кх.. а можно вообще пример "больших" проектов на BSD?:)
> http://ru.wikipedia.org/wiki/Akamai_Technologies ?http://www.internetnews.com/blog/skerner/akamai-cso-andy-ell...
Упс?
> Упс?И где там написано "мы не используем openbsd"?
> И где там написано "мы не используем openbsd"?Akamai - это пример большого проекта на Linux, а не на BSD.
>> Упс?
> И где там написано "мы не используем openbsd"?А где вообще написано про опенок в akamai?Только про лин.
> И где там написано "мы не используем openbsd"?Для начала там нигде не написано что они его используют. А когда Akamai отгружает мне файло, операционкой его сервера недвусмысленно детектируется линух, а не опенбсд. И чего бы это вдруг? :)
>> И где там написано "мы не используем openbsd"?
> Для начала там нигде не написано что они его используют. А когда
> Akamai отгружает мне файло, операционкой его сервера недвусмысленно детектируется линух,
> а не опенбсд. И чего бы это вдруг? :)сдается мне что ты врешь..
http://dazzlepod.com/ip/23.7.86.38/
как пример.
> сдается мне что ты врешь..
> http://dazzlepod.com/ip/23.7.86.38/
> как пример.И где там написано, что хост BSD?
>>> И где там написано "мы не используем openbsd"?
>> Для начала там нигде не написано что они его используют. А когда
>> Akamai отгружает мне файло, операционкой его сервера недвусмысленно детектируется линух,
>> а не опенбсд. И чего бы это вдруг? :)
> сдается мне что ты врешь..
> http://dazzlepod.com/ip/23.7.86.38/
> как пример.[root@localhost g]# nmap -A -O -Pn -F -T4 -sV --open 23.7.86.38
Starting Nmap 5.51 ( http://nmap.org ) at 2013-06-08 05:40 EDT
Failed to find device eth0 which was referenced in /proc/net/route
Nmap scan report for a23-7-86-38.deploy.akamaitechnologies.com (23.7.86.38)
Host is up (0.18s latency).
Not shown: 97 filtered ports
PORT STATE SERVICE VERSION
25/tcp open smtp Postfix smtpd
80/tcp open http AkamaiGHost (Akamai's HTTP Acceleration/Mirror service)
|_http-title: Invalid URL
|_http-methods: No Allow or Public header in OPTIONS response (status code 400)
443/tcp open ssl/http AkamaiGHost (Akamai's HTTP Acceleration/Mirror service)
|_http-title: Invalid URL
|_http-methods: No Allow or Public header in OPTIONS response (status code 400)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: switch|general purpose
Running (JUST GUESSING): HP embedded (88%), Linux 2.6.X (88%)
Aggressive OS guesses: HP Brocade 4Gb SAN switch (88%), Linux 2.6.15 - 2.6.26 (88%), Linux 2.6.9 (CentOS 4.4) (88%), Linux 2.6.9 - 2.6.27 (88%), Linux 2.6.9 (86%)
No exact OS matches for host (test conditions non-ideal).
Service Info: Host: relay2.beelinegprs.ruTRACEROUTE
HOP RTT ADDRESS
1 177.62 ms a23-7-86-38.deploy.akamaitechnologies.com (23.7.86.38)OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 46.21 seconds
Где тут openbsd?
> сдается мне что ты врешь..С вашим то ником? Не удивительно что вас глючит.
> как пример.
Как пример могу посоветовать посмотреть чем майкрософтушка отгружает свои даунлоады (они как раз AKAMAI CDN юзают IIRC). Очень забавно смотрится сервант с линухом, отгружающий MSовские даунлоады.
>> Примеры "больших" взломов проектов на BSD в студию, а такие ещё остались.
> Кх-кх.. а можно вообще пример "больших" проектов на BSD?:)Yandex.ru, и сюда гляньте http://uptime.netcraft.com/perf/reports/Hosters
> Yandex.ru,Это те которые на убунту переходят, потому что виртуализация? :)
> и сюда гляньте http://uptime.netcraft.com/perf/reports/Hosters
А там про размеры хостеров вообще ни звука...
>> Yandex.ru,
> Это те которые на убунту переходят, потому что виртуализация? :)Никто там на самом деле никуда не переходит, ставили для тестинга и для начала несколько
убунт, после чего вернули всё обратно на бсд.
>> и сюда гляньте http://uptime.netcraft.com/perf/reports/Hosters
> А там про размеры хостеров вообще ни звука...Про размеры узнаете на сайтах самих этих хостеров.
> убунт, после чего вернули всё обратно на бсд.Не знаю что они там "все" вернули на BSD, но даже тот же неткрафт видит у них хосты с линуксом и при том - явно чаще чем бсд. Хотя основная масса хостов там unknown, плюс у них куча доменов отличных от *.yandex.ru, есть, а все их вычислять и лукапать мне было лень.
> Про размеры узнаете на сайтах самих этих хостеров.
А на сайтах хостеров традиционно висит всякий маркетинговый буллшит, с рассказом о том какая компания замечательная. Ну конечно, сам себя не похвалишь - никто не похвалит. Вот только интересуют фактические сведения, а их на сайте у хостеров обычно не вывешивают, считая их своим внутренним делом.
> Не знаю что они там "все" вернули на BSD, но даже тот
> же неткрафт видит у них хосты с линуксом и при том
> - явно чаще чем бсд. Хотя основная масса хостов там unknown,
> плюс у них куча доменов отличных от *.yandex.ru, есть, а все
> их вычислять и лукапать мне было лень.В yandex на freebsd только поиск, всё остальное на Linux.
> В yandex на freebsd только поиск, всё остальное на Linux.Ну вот это здорово отличается от того маркетингового буллшита который втер анонимус выше. Он утверждал что "все" вернули. А простейший лукап в неткрафте показал что это трындеж.
Для пустозвонов и студентов мс да, явно.
Для остальных явно пока только одно — нефиг агента нагиос от рута пускать какая бы ОС не стояла.Зыж
Возможно (возможно!) таким конторам стоит юзать харденед и/или селинух и тд.
Очевидно о безопасности процессов нужно тоже заботиться.
> нефиг агента нагиос от рута пускатьтак обычно же он от "nagios" работает (не ставил, диванно кукарекаю)
>> нефиг агента нагиос от рута пускать
> так обычно же он от "nagios" работает (не ставил, диванно кукарекаю)Вопрос шире, чем твой диван. На кой ставить на сервера Nagios? И вообще любые проги, не являющимися необходимыми для администрирования конкретных аппаратов.
>>> нефиг агента нагиос от рута пускать
>> так обычно же он от "nagios" работает (не ставил, диванно кукарекаю)
> На кой ставить на сервера Nagios?на той, что без nrpe он обычно бесполезен чуть более, чем полностью.
ну и да, мудрые советы наподобие http://linuxdrops.com/solve-nrpe-unable-to-read-output-when-.../ решают же.
> Ну и какая операционка там используется?Явно здесь linux виноват.Уже много
> свидетельств о проломах в linux серверах, может,всё таки рано хоронят *bsd системы?И
> на более ответственные машины ставить их?Изень, залогинься.
поразительно. такой примитивный вброс, а у половины юзеров пуканы в клочья
А как происходит изменение процесса в памяти? Сегменты кода должны быть read-only. Или все это дело живет внутри подгруженного модуля?
Было бы классно иметь syscall, который бы считал чексумму от сегментов кода процесса.
а производительность насколько бы просела от таких аттракционов?
Производительность здесь совершенно не важна. У вас производительность тоже подсядет, если вы fork бомбу запустите - никто ж поэтому fork() не выпиливает.
ну а толку то?
ну посчитал, увидел что сумма другая, дальше то что? это нормальное поведение этого ПО или его взлом?зыж
уже все давно придумано, просто всем лень это использовать пока жареный петух не клюнет.
вот http://ru.wikipedia.org/wiki/Hardened_Gentoo
тут подробнее http://habrahabr.ru/post/13094/
http://openbsd.org/lyrics.html#53
Что сказать то хотел, болезный?
> Что сказать то хотел, болезный?Неуловимый Джо испытывает батхерт от того что он настолько уныл что его даже ловить никто не желает.
... хотя батхёрт должен испытывать Уловимый Джо, его что-то часто улавливают в последнее время. Улавливают и улавливают кверху задницей. Что весьма уныло, несмотря на мантры "лынуск безопасни".
> на мантры "лынуск безопасни".Так где улов то? Я пока не вижу никаких заявок со стороны Hetzner о том что кто-то как-то эскалировал права через дырку в ядре. Эти мысли пока идут только от фанов бздей и тому подобных ископаемых.
А так - да, блин, если у хостера серваки с линем, чертовски логично что при их взломе серваки с BSD не сломают. За их отсутствием. Сложно сломать то чего нет. Illumos всякие - да блин, хакеры хоть 1 такой сервак живой искать заманаются, т.к. редкий вид. И бзды кроме рунета мало где уже остались.
> http://openbsd.org/lyrics.html#53Знаешь, клоун, мне от операционки надо не красивую лирику, а нормальную работу с моим оборудованием и обслуживание моих задач. Вот по каким-то таким причинам оно и непопулярно. Лирика - это прекрасно, конечно, но от операционки требуется немного не это.
> а производительность насколько бы просела от таких аттракционов?На столько на сколько часто ты бы дергал это. Сама по себе идея нормальная, кстати.
Да постоянно дергать смысла нет. Не знаю как было бы правильно, нужно еще помнить о dlopen(). Потому что при старте того же аппача у него будет одна cksum и при подгрузке им модулей, она будет меняться.
> Да постоянно дергать смысла нет.Ну не постоянно, а изредка - такой вот фоновый скан. Вполне нормальная идея, ее подвиды были реализованы в разных параноидальных конструкциях даже.
> Не знаю как было бы правильно, нужно еще помнить о dlopen().
> Потому что при старте того же аппача у него будет одна cksum и при
> подгрузке им модулей, она будет меняться.Ну да, программы могут в принципе подгружать/выгружать либы после запуска. Можно LD_PRELOADом вгрузить им либы заранее, но сие костыль :)
> Да постоянно дергать смысла нет. Не знаю как было бы правильно, нужно
> еще помнить о dlopen(). Потому что при старте того же аппача
> у него будет одна cksum и при подгрузке им модулей, она
> будет меняться.Это тупиковый путь, который уже был изучен вендой. Допустим торвальдс запилит такой сисколл. Поттеринг^W Кто-нибудь запилит мониторящий процесс. Затем появится руткит, который будет подделывать результаты возвращаемые сисколлом. Придётся изобретать ещё один сисколл, который будет проверять первый сисколл на наличие патча. [...] В общем, гонка вооружений.
а уж как авторы jit'ов-то будут рады!
> а уж как авторы jit'ов-то будут рады!А процессов с JIT относительно немного. И кстати их я бы считал "потенциально проблемными", т.к. зачастую они довольно навороченные и при этом заведомо могут запись и выполнение, что делает такую сущность довольно удобной для атаки. Даже думать не надо что делать с W^X :)
>> а уж как авторы jit'ов-то будут рады!
> А процессов с JIT относительно немного.а будет много. к тому идёт.
> а будет много.Каких и нафига?
разных и затем.
> разных и затем.Не догоняю зачем мне это. У тебя может и будет. Флаг тебе в руки. А для меня "затем" не является достаточным аргументом для размещения в системе всякого барахла, извини.
да кто ж спрашивать-то будет?
> да кто ж спрашивать-то будет?Так это, а мне и не требуется ничье ослиное позволение чтобы содержать в системе только то что я хочу видеть и выпнуть оттуда лишнее. Поэтому если автор программы упоролся - она просто пойдет под деинсталл. Вроде бы довольно просто.
> Вроде бы довольно просто.до тех пор, пока аналоги есть.
написание прикладного софта и мелкоутиля на скриптовых языках нынче — тен-ден-ци-я. в общем-то, это даже правильно. и количество такого софта будет расти. на ц/цпп это всё никто переписывать, понятно, не будет. так что увы.
> до тех пор, пока аналоги есть.Так а куда они денутся то? Ну не испарятся же они в момент, eh? :)
> написание прикладного софта и мелкоутиля на скриптовых языках нынче — тен-ден-ци-я.
Ну знаешь, а если все подорвутся в пропасть прыгать - я что, тоже должен за ними чтоли прыгать? Перебьются, пусть сами свой шит и юзают. А я тут при чем? :)
> в общем-то, это даже правильно. и количество такого софта будет расти.
> на ц/цпп это всё никто переписывать, понятно, не будет. так что увы.Ну так пусть сами своим тормозным крапом и пользуются. А я тут при чем? Тем более что jit там только в самом интерпретере. Ну и если уж на то пошло, в скриптовом крапе обычно актуальнее другие типы дыр. Поскольку "приложения" на скриптах пишут сказочные ДЛБ с соответствующей квалификацией, дыры там не менее жесткие, но - других типов. Как ивзестно, "дyрак и оругцом порежется".
>> до тех пор, пока аналоги есть.
> Так а куда они денутся то? Ну не испарятся же они в
> момент, eh? :)всё развивается. появляется новое. появится какая-нибудь интересная штука, или у старой апи поменяется — а управлялка штукой только на гвидобейсике. старые уже не работают.
>> написание прикладного софта и мелкоутиля на скриптовых языках нынче — тен-ден-ци-я.
> Ну знаешь, а если все подорвутся в пропасть прыгать — я что,
> тоже должен за ними чтоли прыгать? Перебьются, пусть сами свой шит
> и юзают. А я тут при чем? :)при том, что ты не пишешь для себя весь софт сам.
> апи поменяется — а управлялка штукой только на гвидобейсике. старые уже не работают.Ну окей, я не буду пользоваться этой штукой. Мне не трудно. В убунте я первым делом поделия на гвидобэйсике как раз и вытряхиваю. Прямо по критерию "гвидобэйсик в зависимостях". И знаешь, самые падучие и глючные компоненты как оказалось - именно на оном и написаны. Ну логично что если при разработке гнали как на пожар, да еще на гвидобэйсике - получится то что и должно было получиться.
А всякие там зонды^W кульные синхронизации с чужими серваками типа ubuntu one, твиттеры-фигиттеры, и прочая буитень ради которой имеет смысл юзать гвидобэйсик - меня очень слабо интересует.
> при том, что ты не пишешь для себя весь софт сам.
Так его готового навалом на все вкусы :). И что интереснее - он никуда особо не денется.
> Это тупиковый путь, который уже был изучен вендой. Допустим торвальдс запилит такой
> сисколл. Поттеринг^W Кто-нибудь запилит мониторящий процесс. Затем появится руткит,
> который будет подделывать результаты возвращаемые сисколлом. Придётся изобретать
> ещё один сисколл, который будет проверять первый сисколл на наличие патча.
> [...] В общем, гонка вооружений.Вы все правильно поняли. Теоретически, ни одна программа не может полностью анализировать другую программу с выдачей определенного вердикта относительно ее поведения.
http://0xfeedface.org/sites/default/files/2013%20Libhij...
> http://0xfeedface.org/sites/default/files/2013%20Libhij...Ага, неуловимых бсдшников оказывается вполне можно вполне красиво вздрючивать. Впрочем опсанные техники прменимы не только к *bsd.
1) А что, ALSR там до сих пор не сделали что гражданин ищет ELF хидер по фиксированному адресу?
2) Он что, изобрел довольно известный прикол класса ret2libc? [Кстати на ARM этот номер не работает в силу технических особенностей :P].
3) Я не понял, а бсдшники что, до сих пор позволяют кому попало фигачить ptrace() вообще без ограничениий? В лине вон уже доперли что тут порыты некислые грабли и теперь на трассировку во всех культурных дистах по дефолту есть ограничения, в общем случае без проблем трейсить и дебажить может только рут. Остальное ... остальное надо явно разрешать, на свой страх и риск, скомандовав кернелу, что опять же может только рут. Продакшн серверам отладка от юзера не упала, так что -1 потенциально проблемная фича.
>> http://0xfeedface.org/sites/default/files/2013%20Libhij...
> Ага, неуловимых бсдшников оказывается вполне можно вполне красиво вздрючивать. Впрочем
> опсанные техники прменимы не только к *bsd.
> 1) А что, ALSR там до сих пор не сделали что гражданин
> ищет ELF хидер по фиксированному адресу?В NetBSD ASLR, ты даже абревиатуру толком не знаешь, с 2004-ого года.
PIE тогда же. В OpenBSD еще раньше.> 2) Он что, изобрел довольно известный прикол класса ret2libc? [Кстати на ARM
> этот номер не работает в силу технических особенностей :P].Это каких, например?
> 3) Я не понял, а бсдшники что, до сих пор позволяют кому
> попало фигачить ptrace() вообще без ограничениий?Нет. В NetBSD с помощью kauth(9) ptrace можно вообще запретить.
Кроме того, по умолчанию запрещено трейсить процессы из chroot-а,
даже от root-а. Плюс есть ограничения при разных security levels.http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
http://wiki.netbsd.org/kernel_secure_levels/
>[оверквотинг удален]
>> 2) Он что, изобрел довольно известный прикол класса ret2libc? [Кстати на ARM
>> этот номер не работает в силу технических особенностей :P].
> Это каких, например?
>> 3) Я не понял, а бсдшники что, до сих пор позволяют кому
>> попало фигачить ptrace() вообще без ограничениий?
> Нет. В NetBSD с помощью kauth(9) ptrace можно вообще запретить.
> Кроме того, по умолчанию запрещено трейсить процессы из chroot-а,
> даже от root-а. Плюс есть ограничения при разных security levels.
> http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
> http://wiki.netbsd.org/kernel_secure_levels/Так всё-таки есть в BSD рандомизация.Встречал статейку Криса Касперски, где он
рассказывал о том, что с ней возятся в linux и win, в unix она с древнейших времён, а
в BSD с этим плохо.В NetBSD её нет вообще в free она не вменяема, только в OpenBSD есть,
но и там почти отключена по соображениям производительности.
> Встречал статейку Криса Касперскизачем ты такую херню читаешь?
>[оверквотинг удален]
>> Кроме того, по умолчанию запрещено трейсить процессы из chroot-а,
>> даже от root-а. Плюс есть ограничения при разных security levels.
>> http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
>> http://wiki.netbsd.org/kernel_secure_levels/
> Так всё-таки есть в BSD рандомизация.Встречал статейку Криса Касперски, где он
> рассказывал о том, что с ней возятся в linux и win, в
> unix она с древнейших времён, а
> в BSD с этим плохо.В NetBSD её нет вообще в free она
> не вменяема, только в OpenBSD есть,
> но и там почти отключена по соображениям производительности.Гражданин хороший, ты несешь полный бред, абсолютно проитивоположный
действительности. Крис Касперски -- дебил, ты нашел кого читать.
Начнем с того, что рандомизация рандомизации рознь.
Тебе рандомизацию чего подать? ASLR/PIC? Она совершенно точно есть
в NetBSD и OpenBSD, во FreeBSD AFAIK нет, пусть меня поправят.
ASLR/PIC в OpenBSD таки включен по умолчанию, как в ключен по умолчанию
теперь уже в некоторых дистрибутивах Линупса,
в NetBSD он рыключен, ASLR включается sysctl, а PIE можно добиться
перекомпилированием системы, по умолчанию экзешники скомпилены без PIC.
То же касается pkgsrc -- все как у upstream-а, включен PIC -- будет,
нет -- досвидос.
Рандомизация pid при форках в OpenBSD AFAIK есть и по умолчанию включена.
Исторически в UNIX-ах никакой рандомизации как раз не было, посколько
не было position independent code до появления ELF. По этой же причине
ASLR нет в винде, там PIC нет ввиду убогово coff, адреса загрузки dll
определяются в момент компиляции.
> а PIE можно добиться перекомпилированием системы, по умолчанию
> экзешники скомпилены без PIC.Все вы в этом. Такие вещи должны быть по дефолту. Т.к. уповать на то что рядовой эксплуатационщик будет доктором наук - не приходится, отнюдь. Я думаю вы теперь понимаете почему ваша система с таким подходом никогда не займет сколь-нибудь внятной рыночной доли на серверах?
>> а PIE можно добиться перекомпилированием системы, по умолчанию
>> экзешники скомпилены без PIC.
> Все вы в этом. Такие вещи должны быть по дефолту.Я с тобой согласен, но есть/были ТЕХНИЧЕСКИЕ причины, почему это выключено.
http://mail-index.netbsd.org/tech-security/2011/12/05/msg000...
В каком это сейчас статусе я не в курсе.> Т.к. уповать на то что рядовой эксплуатационщик будет доктором
> наук - не приходится, отнюдь.В отличие от Линукса NetBSD собирается с любыми опциями на любой
UNIX-like системе кроссово одной командой. Сборка системы
не требует докторской степени.> Я думаю вы теперь понимаете почему ваша система с таким
> подходом никогда не займет сколь-нибудь внятной рыночной доли на серверах?Ваше мнение очень важно для нас.
> Я с тобой согласен, но есть/были ТЕХНИЧЕСКИЕ причины, почему это выключено.
> http://mail-index.netbsd.org/tech-security/2011/12/05/msg000...Как это назвать? "Broken and Late, Ltd".
> В каком это сейчас статусе я не в курсе.
Если честно - я вообще не понял такое решение. Называя вещи своими именами, на серверах сейчас царит х86_64, у которого регистровый файл относительно нормальный и relative-адресация есть, по поводу чего PIC для него вообще не должен являть собой никаких проблем. Я конечно не занимался хардкорными бенчами, но особого падения скорости от PIC не заметил нигде так сходу. Тем более что чисто-локальные программы, не имеющие дел с внешним миром с ним можно и не собирать. Всякая околоэмбедовка - у ARM и MIPS все нормально с регистрами. В честь чего этот огород про архитектуры с куцым набором регистров?
> В отличие от Линукса NetBSD собирается с любыми опциями на любой
> UNIX-like системе кроссово одной командой.Если честно - I don't care. Для вас это достоинство. Для меня - бесполезный артефакт. Я все-равно буду иметь дело с системой из-под нее самой. Потому что это right way of doing things на мое нескромное мнение.
> Сборка системы не требует докторской степени.
В общем случае, задача эксплуатационщика - кнопки на пульте жать, а не строить самому себе ядерный реактор. У академиков как-то традиционно плохо с пониманием этого момента.
> Ваше мнение очень важно для нас.
А по бздам это заметно. Собственно, поэтому ими и пользуется горстка маргиналов. Остальные нашли себе более удобные и менее геморные системы. Благо бзды не единственные в мире, к счастью.
> Если честно - I don't care. Для вас это достоинство. Для меня
> - бесполезный артефакт. Я все-равно буду иметь дело с системой из-под
> нее самой. Потому что это right way of doing things на
> мое нескромное мнение.Расскажите как там у linux с крос компиляцией? и почему redhat запрещает это делать - тоже расскажите (не поставляет пакеты и объявляет не поддерживаемым это).
> Расскажите как там у linux с крос компиляцией?Нормально. Я вот только что образ openwrt под мипс с x86_64 хоста себе зафигачил. Вполне себе кросскомпиляция. Как видите, все прекрасно работает. Там где это реально надо. Хотя можно и демонстративно истекать словесным поносом на форуме, тоже вариант.
> и почему redhat запрещает это делать
> - тоже расскажите (не поставляет пакеты и объявляет не поддерживаемым это).Так у них и спросите. Могу предположить что их данный сценарий использования не интересует (они на эмбеддовку не метят в данный момент) и поэтому они не собираются кому-то что-то гарантировать на этот счет.
> В NetBSD ASLR, ты даже абревиатуру толком не знаешь, с 2004-ого года.Уел, бaстард. Я знаю что это и нафига, так что нефиг тут так нагло троллить.
> PIE тогда же. В OpenBSD еще раньше.Ну я рад за них. Осталось найти хоть один сервак с этим. А то у пингвина все это тоже есть, только хаксоры подобное воркэраундить тоже учатся, если что.
> Это каких, например?
Там при переполнении проблематично скормить какие-то осмысленные аргументы вызываемой функции когда возврат делается. ARMовское ABI предполагает в общем случае передачу параметров в регистрах а не стеке (у ARM в отличие от x86 их довольно много). Если при атаке на стек в случае x86 можно и параметры переписать, то в ARM их надо в регистры впихнуть. А это вообще не адрес в памяти, над записью в регистры у атакующего нет прямого контроля. Это делает возврат в функцию с каким-то осмысленным результатом не то что совсем невозможным, но труднореализуемым и не гарантированным.
В лучшем случае, особо продвинутые хакеры умудряются нащупать последовательности кода которые можно подергать так чтобы ничего не испортилось + в конечном итоге в регистрах все-таки образовалось то что было надо. В этом случае ret2libc и тому подобное даже может прокатить. Однако это весьма трудоемко и наличие такого кода - из разряда "уж как повезет". Все это сильно задирает планку для этого класса атак на ARM. Такая вот маленькая интимная особенность ARM ABI, оказавшаяся недружественной к хакерам любящим дерг кода путем возврата на него.
>> попало фигачить ptrace() вообще без ограничениий?
> Нет. В NetBSD с помощью kauth(9) ptrace можно вообще запретить.В большинстве культурных дистров линя нынче трассирование процессов юзерем по дефолту вообще откушено (слишком уж много потенциальных проблем) и надо вообще явно разрешать юзеру трейсить свои процессы (что может сделать только рут, записав соотв. значение в файлик ядерного интерфейса). По дефолту трейсить может только рут. Что спасает от массы грабель. Как видите, у пингвиноидов настройки даже пожестче.
> Кроме того, по умолчанию запрещено трейсить процессы из chroot-а,
> даже от root-а. Плюс есть ограничения при разных security levels.Если вы хотели этим попонтоваться, LXC пожалуй попродвинутее будет с его виртуализацией неймспейсов всех мастей и прочая. Оно вообще ближе к независимым окружениям.
> http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
> http://wiki.netbsd.org/kernel_secure_levels/Ну ок, я должен признать что наезжать на вообще всех бсдшников за пофигизм в секурити - не очень правильно, некоторые все-таки не такие уж и пофигисты в вопросе. Тем не менее, я не вижу что из перечисленного было лучше чем в пингвине, откуда сделаны масштабные выводы о бОльшей защищенности. Пингвины популярны, так что их долбят довольно много. Поэтому от наиболее очевидных типовых напастей они защитились вполне на уровне.
>> Это каких, например?
> Там при переполнении проблематично скормить какие-то осмысленные аргументы вызываемой
> функции когда возврат делается. ARMовское ABI предполагает в общем случае передачу
> параметров в регистрах а не стекеOk, спасибо. Я гляну на досуге, что там и как. С АРМ-ами дел не имею обычно.
>>> попало фигачить ptrace() вообще без ограничениий?
>> Нет. В NetBSD с помощью kauth(9) ptrace можно вообще запретить.
> В большинстве культурных дистров линя нынче трассирование
> процессов юзерем по дефолту вообще
> откушеноКультурные дистры -- это какие? В Debian и RHEL я этого не наблюдаю.
>> Кроме того, по умолчанию запрещено трейсить процессы из chroot-а,
>> даже от root-а. Плюс есть ограничения при разных security levels.
> Если вы хотели этим попонтоватьсяНет. Попонтоваться -- это не ко мне. Я говорю о том, что кое-что сделано
в этом плане и в BSD тоже. Диалог должен быть познавательным для обеих сторон.
За писькомером не ко мне. И да, я в курсе и про lxc и про cgroups и про openvz.>> http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
>> http://wiki.netbsd.org/kernel_secure_levels/
> Ну ок, я должен признать что наезжать на вообще всех бсдшников за
> пофигизм в секурити - не очень правильно, некоторые все-таки не такие
> уж и пофигисты в вопросе.Прекрасно. Культурный диалог состоялся.
> Тем не менее, я не вижу
> что из перечисленного было лучше чем в пингвине, откуда сделаны масштабные
> выводы о бОльшей защищенности.Я не утверждал, что в *BSD что-то лучше или хуже или лучше, чем в Линупсе.
Это твои фантазии ;-) Я лишь указал на документацию.> Поэтому от наиболее очевидных типовых напастей они защитились вполне на уровне.
Я думаю, лучший в отрасли -- grsecurity, откуда собственно
многое в NetBSD и пришло. Но grsecurity в мире Линукса -- такая
же маргинальщина, как NetBSD для типичного Линукс-админа.
AFAIK его нет нигде кроме одного профиля Gentoo.
> Ok, спасибо. Я гляну на досуге, что там и как. С АРМ-ами дел не имею обычно.На это дело можно найти энное количество материала у тех кто интересуется подобными трюками, есть минимум несколко более-менее похожих описаний как хакеры борятся (ну или по крайней мере пытаются) с подобной напастью. Обычно это достаточно замороченные фокусы с попытками сначала дергать какие-то фрагменты кода которые сделают что-то полезное и только потом удастся сделать возврат. Все это тот еще брейнфак и работоспособность такой атаки - очень зависит от внешних факторов, как то найдется ли в атакуемой программе вообще удобный для этого код. Приходит в голову что кроме PIE программам было бы некисло еще и трансформации кода делать, чтобы это дело еще больше усложнить :)
> Культурные дистры -- это какие? В Debian и RHEL я этого не наблюдаю.
На данный момент так делает даже обычная ширпотрeбная убунта и те кто на ней базируются, так что если кто отпускает тормоз медленнее чем они - вообще позор и стыдоба им. Вызовы типа ptrace() считались потенциальным источником проблем и нежелательных действий черт знает сколько времени. В ядре есть механизмы для этого.
> Нет. Попонтоваться -- это не ко мне. Я говорю о том, что кое-что сделано в этом
> плане и в BSD тоже. Диалог должен быть познавательным для обеих сторон.Ну окей, я признал что наезд на "вообще все BSD" все-таки не очень удачный маневр.
> За писькомером не ко мне. И да, я в курсе и про lxc и про cgroups и про openvz.
И kvm тогда уж. Виртуализация и контейнеры конечно не столько средство безопасности, но они вполне могут минимизировать и урон от хакеров при правильном применении. Лишняя граница раздела сред еще никому не мешала в плане уменьшения последствий от хаков.
> Прекрасно. Культурный диалог состоялся.
Ну во всяком случае лучше чем кидания какашками без аргументов.
> Это твои фантазии ;-) Я лишь указал на документацию.
А в чем пойнт? А указывал какой-то соседний гражданин.
> Я думаю, лучший в отрасли -- grsecurity,
По общей степени параноидальности в ее "классическом" виде - пожалуй. Хотя лично мне видится более перспективной рaспилoвка окружений на виртуалки по принципу "1 загoн на сервис". Ну в общем "жизнь после эры чрута". С точки зрения атакующего - ломать такое достаточно неудобно, опять же. Не то чтобы совсем невозможно, но опять же планка поднимается и ущерб минимизируется. Плюс контейнеры "по 1 на сервис" можно при желании довольно дотошно мониторить и отлавливать аномалии по каким-нибудь простым критериям типа "запустились утилиты, хотя httpd в приницпе не должен использовать ls" или "ой, а чего это у нас тут кто-то дергает ptrace()? У нас дебагера тут вообще нет!". Нечто такое сделали на codepad.org - там сначала фильтр сисколов, потом виртуалка. И да, там можно вполне себе севый код пинать. Лично мне вообще не удалось особо поразвлекаться - большинство интересных сисколов зарубается фильтром.
> откуда собственно многое в NetBSD и пришло. Но grsecurity в мире Линукса -- такая
> же мaргинальщина, как NetBSD для типичного Линукс-админа.Зато в каждом линуксном ядре идет система контейнеров и виртуализатор в комплекте. Совершенно нахаляву и даже без лишних усилий - обычно в дистрах эти фичи ядра включены при сборке.
> AFAIK его нет нигде кроме одного профиля Gentoo.
Потому что действительно довольно маргинальная штука. Мне при нужде минимизировать урон от хакеров (защищать дырявый или пробэкдоренный сервис от самого себя будем считать делом тухлым) - проще просто на виртуалки или хотя-бы контейнеры распилить. Так чтобы проблемный сервис сидел в своей песочнице. Если уж его поимели - так поимели. А рут в контейнере/виртуалке мало что и кому дает. Там кроме проблемного сервиса который один фиг раздолбали и не должно ничего быть. Это просто если подумать "а как сделать так чтобы хакеры всерьез чертыхались при попытке серьезно долбить всю инфраструктуру".
p.s. я так и не понял - вот чего я тут ругательного сказал, что б-дский вордфильтр возбух?
> А как происходит изменение процесса в памяти? Сегменты кода должны быть read-only.
> Или все это дело живет внутри подгруженного модуля?например через область REL, в этой области хранятся адреса вызываемых
из shared objects функций. Достаточно подменить адреса в этой области
и будут вызываться твои функции, скажем, system(3) с нужными параметрами ;-).
Гугли на предмет RELRO. Но если речь идет о rootkit-е, то там уже по барабану,
константный сегмент памяти *был* или нет ;-)
> например через область REL, в этой области хранятся адреса вызываемых
> из shared objects функций. Достаточно подменить адреса в этой области
> и будут вызываться твои функции, скажем, system(3) с нужными параметрами ;-).
> Гугли на предмет RELRO. Но если речь идет о rootkit-е, то там
> уже по барабану,
> константный сегмент памяти *был* или нет ;-)Если речь идёт о бекдоре, то там и секции исполняемых файлов трогать не обязательно, можно
замутить скрытый модуль ядра, который будет шарахаться по сегментам каких-то
процессов прямо из ядра, по вызовам с usermode через ioctl-ы.
Запись в память другого процесса этого же юзера задача вроде попроще, чем (собрать/) загрузить .ko, не?
вторая утечка за два года
> поражает процессы Apache и sshd только в оперативной памяти.интеренсно, а какая резидентная морда написала это ? я восхищен
Красиво, чо. Чем-то напоминает некоторые виды msblast.
да чего красивого то? без бекдора то не обошлось.
вот красота http://habrahabr.ru/post/182246/
> обнаружен исходник + компилированная версия эксплоита для повышения локальных прав в ОС Windows: NT/2K/XP/2K3/VISTA/2K8/7/8. Сама уязвимость обнаружена 24 мая 2013 — http://www.cvedetails.com/cve/CVE-2013-3660/
>Патч на данный момент не доступен.вот это да. и во всех версиях виндов сразу.
там локальный эксплоит и для х86, опять что бы запустить такой ВК его надо скачать, а для большенства юзеров винды и этого не надо, они и так под админом сидят в сети.
> они и так под админом сидят в сети.По поводу чего в последних виндах MS изобрел шедевр: админ-который-недоадмин. Так что админа постоянно клюют подтверждениями. В общем sudo они передрали как-то очень криво и по своему.
> По поводу чего в последних виндах MS изобрел шедевр: админ-который-недоадмин. Так что
> админа постоянно клюют подтверждениями. В общем sudo они передрали как-то очень
> криво и по своему.так они же свою аудиторию знают: их «админов» лучше трижды переспросить, а потом всё равно запретить. а то — «уж я вам наработаю!»
> так они же свою аудиторию знают: их «админов» лучше трижды переспросить, а
> потом всё равно запретить. а то — «уж я вам наработаю!»Ну так можно было пинками загонять в непривилегированного юзеря и сделать получение админа неудобным и недефолтным действом. Хотя тогда половина софта посыпалось бы - культуры написания софта ведь нет. Win95 была же без секурити совсем.
>там локальный эксплоит и для х86,А вантуз ещё подо что-то есть?
Где выкрики 95% ломающиеся на ура любым идiотом? Эксплоит даже собирать не надо.
> А вантуз ещё подо что-то есть?Еще под x86_64 и ARM. Правда на ARM он такой убогий вышел, что убедить кого-то это купить вообще не получается.
> да чего красивого то? без бекдора то не обошлось.Да с этим никто и не спорит, просто технологично сработано - чисто in-memory вариант процесса запатчен. Задетектировать сложновато. Это требует хорошей квалификации того кто это делал.
> Это требует хорошей квалификации того кто это делал.Это да, это то что и называлось в моё время хакер.
Но как именно используется ничего гениального. Хотя класс виден.
Именно гениального - ну да, всем кто хоть немного подозревает как работают эксплойты и тому подобное добрецо - было давно понятно, что менять файл на диске в общем то не обязательно, если какая-то особая персистентность взлома не интересует. Вон некоторые виды msblsdt в "дисковой" версии совсем не существовали - только в виде сетевых пакетов и образа в оперативе. Ничему не противоречит.
А я всегда говорил, что nrpe и подобные проги зло. Только net-snmp добро.
Я одинаково отношусь как к Linux/GNU так и к BSD, но стоит посмотреть на Linux и сразу становится понятно что выпуск ядра поставлен на конвейер. Выпуски очень регулярны, основные изменения это добавление новых драйверов. Дистрибутивы кое что добавляют в само ядро а какое что в виде модулей, причем стараются собрать все модули которые есть. Возникает вопрос когда разработчики успевают проводить аудит кода и стабилизацию кодовой базы. Сейчас речь идет только о ядре, но у ядра еще есть окружение из нескольких десятков компонентов, и у некоторых из них тоже конвейерные релизы.С BSD системами, ситуация немного иная ядро пилят постепенно кучу всего не добавляют. Минимальное окружение тоже разрабатывается тем же сообществом что и ядро, что уже хорошо. Ну а вот в остальном отличий от Linux/GNU отличий нет ПО одно и тоже
>>> С BSD системами, ситуация немного инаПростите, конечно, но да - действительно иная. Драйверов нет, поддержка железа на уровне окаменелого г-на мамонта, оптимизация под архитектуру никакая, в сетевом стеке - костыль на костыле и костылём погоняет. Если заходить с этой точки зрения - то зря вообще автомобиль изобрели - с лошадьми ситуация немного иная.
> Простите, конечно, но да - действительно иная. Драйверов нет, поддержка железа на
> уровне окаменелого г-на мамонта, оптимизация под архитектуру никакая, в сетевом стеке
> - костыль на костыле и костылём погоняет. Если заходить с этой
> точки зрения - то зря вообще автомобиль изобрели - с лошадьми
> ситуация немного иная.Я же написал что отношусь к ним одинаково, и во многом не совсем положительно. Системы стараются быть настолько универсальными что излишне раздуваются от релиза к релизу. Это касается как Linux/GNU, так BSD, и да у BSD с драйверами проблемы, но с оптимизацией и качеством проблемы у обоих систем.
Linux/GNU — Это чистокровный мустанг, по крайне мере так было на старте, но к финишу придет загнанная лошадь.
BSD - никуда не спешат, они живут открытием 80 годов, если провести аналогию то они едут вокруг света на пони.
>> Linux/GNU — Это чистокровный мустанг, по крайне мере так было на старте, но к финишу придет загнанная лошадь.Лошадь мертва, хорошая годная конская колбоса
> BSD - никуда не спешат, они живут открытием 80 годов, если провести
> аналогию то они едут вокруг света на пони.Какая глупая стереотипщина. Учитывая то, что сравнивать даже самые популярные FreeBSD, OpenBSD и NetBSD бессмысленно, у них из общего только предок.
>> BSD - никуда не спешат, они живут открытием 80 годов, если провести
>> аналогию то они едут вокруг света на пони.
> Какая глупая стереотипщина. Учитывая то, что сравнивать даже самые популярные FreeBSD,
> OpenBSD и NetBSD бессмысленно, у них из общего только предок.Глупо то что вы считаете название существенным отличием. От предка этим проектам досталась идеология которая за последние 30 лет мало изменилась. Не умение адаптироваться, неизбежно приведет к музейной полке. Конечно хорошо иметь выдерживанию временем идеологию, но в музей ходят не все. Отличия BSD систем настолько минимальны, что их смело можно вместить в 1%. Тоже самое касается и Linux дистрибутивов.
> Не умение адаптироваться, неизбежно приведет к музейной полке. Конечно хорошо иметь выдерживанию временем идеологию, но в музей ходят не все.Данный стереотип имеет мало отношения к реальности. Да, у openbsd разные ценности с поколением айфонов и твитеров... но цивилизация, основанная на айфонах и твитерах умрёт через 20 минут. а openbsd вас всех переживёт. И это правильно, все не должны делать одно и то же, потому что мир разный, люди в нём разные. Мода на мишуру пройдёт, и все вернутся к истинным ценностям. :)
ps. У меня есть архив всех публичных версий openbsd. И я их ставил, смотрел отличия, перечитывал новости: развитие впечатляет.
> Отличия BSD систем настолько минимальны, что их смело можно вместить в 1%.Глупость.
>> openbsd вас всех переживётНу, в общем, да. Окаменелые останки мамонта и сейчас являются находками, пережившими множество поколений. Вот только ценность у них исключительно археологическая.
> Данный стереотип имеет мало отношения к реальности.Если уже устать подтасовывать факты и просто посмотреть на мир вокруг - можно обнаружить что у разных BSD есть кое-что общего. Они нaфиг никому не сдались. Достаточно на рыночную долю и ее изменение посмотреть.
> Да, у openbsd разные ценности с поколением айфонов и твитеров...
Понимаешь ли, у операционки ценность понятная всем по большому счету одна: она обеспечивает работу компьютеров и запуск на них программ. По поводу остальных ценностей мнения могут варьироваться и поэтому их ценность менее очевидна в контексте операционок.
Все-таки приоритеты надо расставлять правильно. А когда у вас только идеология + голый зад в виде неюзабельной операционки, выглядит как-то не очень. И больше смахивает на секту чем команду программистов.
> но цивилизация, основанная на айфонах и твитерах умрёт через 20 минут.
> а openbsd вас всех переживёт.Окаменелые останки мамонта тебя тоже переживут. Что не делает их сильно полезным артефактом.
> и все вернутся к истинным ценностям. :)
Окаменелые останки мамонта представляют интерес для археологов в основном.
> ps. У меня есть архив всех публичных версий openbsd. И я их
> ставил, смотрел отличия, перечитывал новости: развитие впечатляет.А если посмотреть развитие линевого ядра, то можно серьезно задолбаться читать не то что коммиты, а даже просто ченжлог.
> Данный стереотип имеет мало отношения к реальности. Да, у openbsd разные ценности
> с поколением айфонов и твитеров... но цивилизация, основанная на айфонах и
> твитерах умрёт через 20 минут. а openbsd вас всех переживёт. И
> это правильно, все не должны делать одно и то же, потому
> что мир разный, люди в нём разные. Мода на мишуру пройдёт,
> и все вернутся к истинным ценностям. :)Это что намек на то что знание OpenBSD спасет мир. Идеология это хорошо, но не стоит с ней перебарщивать. Например вспомните времена когда металлы ковали в кузницах, сейчас тоже куют но иначе хотя некоторая старая идеология осталась. Однако это не повлияло негативно на процесс развития отрасли, скорее наоборот повлияло положительно. А вот OpenBSD через какое то время можно будет запустить только на том компьютере который будет стоять рядом с ним на полке в музее.
> Это что намек на то что знание OpenBSD спасет мир.Кто бы намекнул фанату марки что его рецепт отливки серебряных пуль немного утомил...
> зря вообще автомобиль изобрели - с лошадьми ситуация немного иная.И вообще, лошать не жрет бензин и коробка передач у нее сломаться не может. Сплошные достоинства! И чего это все как дyраки в каких-то глупых железных коробках с кучей проблем ездят?!
> И вообще, лошать не жрет бензин и коробка передач у нее сломаться
> не может. Сплошные достоинства! И чего это все как дyраки в
> каких-то глупых железных коробках с кучей проблем ездят?!От чего же так сразу. Появились автомобили, появились телефоны. Люди стали разговаривать за рулем по телефону, через некоторое время появилась в авто возможность не держать телефон в руке что бы по нем разговаривать. Это и есть адаптация под современные нужды
А русский язык папуасы так и не выучили. Печалька :(.
> что уже хорошо. Ну а вот в остальном отличий от Linux/GNU отличий нет ПО одно и тожеАга, только драйверов нет, виртуализация у большинства *bsd в полной лузе, etc. И в результате оно как-то так сдуолсь на серверах. Потому что полутрупы на сервере мало кому надо. Вон тут новость была - 51% серверов на основе х86 нынче использует виртуализацию. Ну а кому-то 51% пирога заведомо не достанется. Все хорошо, прекрасная маркиза.
> Ага, только драйверов нет, виртуализация у большинства *bsd в полной лузе, etc.
> И в результате оно как-то так сдуолсь на серверах. Потому что
> полутрупы на сервере мало кому надо. Вон тут новость была -
> 51% серверов на основе х86 нынче использует виртуализацию. Ну а кому-то
> 51% пирога заведомо не достанется. Все хорошо, прекрасная маркиза.Не спорю, визуализация сейчас важна, но упоминая общие ПО я подразумевал например make, perl, и так далее. Но с виртуализацией замечание абсолютно уместное.
> Не спорю, визуализация сейчас важнабгг.. да тебе всё равно о чём писать?
> Не спорю, визуализация сейчас важна,Ну да, я как-то так и подозревал что вы виртуализацию видели только на картинке. Наверное потому и "визуализация".
> но упоминая общие ПО я подразумевал например make, perl, и так далее.
Указанное ПО вообще никакой особой самоценности для большинства людей вообще не представляет. Ну, знаете, примерно как монокристалл кремния для лично вас будет бесполезен: вы же не чипмейкер и не будете наращивать на нем себе процессор сами, так? Спору нет, монокристалл кремния - штука хорошая. Но ценность сам по себе представляет отнюдь не для всех.
> Но с виртуализацией замечание абсолютно уместное.
Если б только с ней.
> Ну да, я как-то так и подозревал что вы виртуализацию видели только
> на картинке. Наверное потому и "визуализация".Виртуализация в BSD то есть частично, например в NetBSD есть Xen, во FreeBSD пилят контейнеры. Но в одном дистрибутиве эти обе разработки пока не собрались, и вряд ли соберутся.
А про make, perl я имел ввиду что по сути ПО везде одинаковое, что в Linux что в BSD. Для большинства данное ПО конечно не представляет интереса а вот для BSD систем это неотъемлемая часть.
P.S. Ошибка LibreOffice слово виртуализация не знает и заменяет его на визуализация, но дело не в этом. Указывать мне на орфографию нет смысла тут есть индивидуумы которые вообще словесно не выражаются, а используют «Бгг»
> Виртуализация в BSD то есть частично, например в NetBSD есть Xen,Это который Linux Foundation теперь курируется? Попробую угадать с трех раз где он будет в результате работать лучше, что будут первым делом поддерживать средства управления и так далее.
> во FreeBSD пилят контейнеры.
Проблема только в том что в линухе их не только запилили. Все это уже годы и годы эксплуатируется на коммерческой основе для предоставления услуг. И оно куда как фичастее и в состоянии обеспечивать нужды хостеров.
> Но в одном дистрибутиве эти обе разработки пока
> не собрались, и вряд ли соберутся.А вот в пингвине в одной ОС есть и контейнеры и виртуализатор, прикиньте? Более того - оно обычно сразу "out of the box" есть. Дошло до того что даже хромиум обычный в лине себя в отдельный контейнер силами LXC отпиливает. Ну а что, если фича в ОС есть, а архитектура программы так и просится на такие меры - странно было бы не юзануть.
> А про make, perl я имел ввиду что по сути ПО везде одинаковое,
По сути ПО везде одинаковое. Но вот фич ядра это не касается. И поддержки оборудования, etc. Линовое ядро натурально поддерживает больщую часть железа и умеет массу приятных ништяков. Чем оно всем и симпатично собственно.
> что в Linux что в BSD. Для большинства данное ПО конечно не представляет интереса
> а вот для BSD систем это неотъемлемая часть.Ну так кто им доктор? Лично я вообще не допираю нафиг мне на сервере make, например. Чтоюы хакерью было проще собирать эксплойты? Во спасибо :)
> P.S. Ошибка LibreOffice слово виртуализация не знает и заменяет его на визуализация,
Вы что, ходите на опеннет из либрофиса? oO
вот ядро VPS виртуализации для фри http://7he.at/freebsd/vps/
и кому оно нужно?
А ведь не только к ним прилетело...Jun 2 06:31:05 sshd[10053]: Accepted password for icinga from 195.24.78.226 port 59074 ssh2
Голову вчера сломал, как так: IP не перебирали, логины не перебирали... Сразу пришли. Отвечающий сервис в последние год-полтора только ssh, icinga снесена была несколько лет назад (сервер для экспериментов разных). Видать, хэш упёрли давным давно, подобрали, а сейчас прошлись по всем попавшимся когда-то.
Подсадили "Process Stack Faker", код которого на гитхабе живёт, как оказалось.
а ведь говорят умные люди: меняйте пароли периодически, меняйте. даже на машинах, которые «да кому они нужны вообще!»
Тут не так. "нехрен системного пользователя заводить с шелом". Ставил бы сам, под этой icinga вообще бы зайти нельзя было. Но вот "товарища сотрудника" я не проверил в своё время... Результат, как бы, вот...
> Тут не так. «нехрен системного пользователя заводить с шелом».одно другому не мешает.