Компания Immunity, Inc., занимающаяся исследованиями в области компьютерной безопасности, выпустила (http://lists.immunitysec.com/pipermail/dailydave/2008-Septem...) руткит DR Linux 2.6 (http://www.immunityinc.com/resources-freesoftware.shtml) (Debug Register Rootkit для Linux ядра 2.6.x), реализующего принципиально новую технику скрытия сетевых сокетов, файлов и процессов злоумышленника. В рутките (rootkit) также предусмотрена возможность удаленного управления, через специально разработанный бэкдор, работающий в виде скрытого пользовательского процесса.
Кроме того, автоматически скрываются дочерние процессы и сокеты, порождаемые спрятанными программами, при этом для таких программ все скрытые руткитом ресурсы являются открытыми. Установка DR Linux 2.6 производится через загрузку модуля ядра.
Вместо классического перехвата обработки системных вызовов или таблицы прерываний (IDT), которые легко обнаруживается утилитами для анализа системы на предмет наличия скрытого ...URL: http://lists.immunitysec.com/pipermail/dailydave/2008-Septem...
Новость: http://www.opennet.me/opennews/art.shtml?num=17753
>Компания Immunity, Inc., занимающаяся исследованиями в области компьютерной безопасности, выпустила руткитТак вот кто тут вирусню пишет... Кто проплатил? Или пеАр?
These tools have been released under the GNU Public License by Immunity. By releasing tools, such as these, we hope to demonstrate our knowledge leadership, and give back to the security community as a wholeЭто не вирус!
GNU это вирус для мозгов.
>GNU это вирус для мозгов.А мне этот вирус нравится :) он живет в симбиозе с его носителями.Так же как есть вредные бактерии а есть полезные.Вот от этого вируса я пока вижу тольуо пользу.И для себя и не только для себя.
>Это не вирус!И правда, руткит - это не вирус :) но кое-что общее у них есть: в случае если его вам без вашего ведома установят вы тоже не будете в восторге :)
Всегда,когда собираю ядро для сервера отключаю модули вообще)
>Всегда,когда собираю ядро для сервера отключаю модули вообще)мне жаль ваших серверов, такого кернел-тирана надо поискать
>>Всегда,когда собираю ядро для сервера отключаю модули вообще)
>
>мне жаль ваших серверов, такого кернел-тирана надо поискатьНу, расскажите тогда, зачем на сервере модули.
Никогда не умирала сетевушка или скази-контроллер?
>Никогда не умирала сетевушка или скази-контроллер?ну и чем модули помогут умершей сетевушке и тем более скази-контроллеру?
зы:
сразу скажу, что само ядро не падает, т.к. опыт имеется
>>Никогда не умирала сетевушка или скази-контроллер?
>
>ну и чем модули помогут умершей сетевушке и тем более скази-контроллеру?
>зы:
>сразу скажу, что само ядро не падает, т.к. опыт имеетсяАналогишно. Никаких модулёв! Собрал и вот вам.
Есть возможность хотя бы контролировать факт подгрузки модуля.
>>Никогда не умирала сетевушка или скази-контроллер?
>ну и чем модули помогут умершей сетевушке и тем более скази-контроллеру?А что, кроме замены сетевушки будете еще и перекомпиливать кернель?А за даунтайм не закопают?Хотя если паранойя долбит - отключка загрузки модулей самое оно.
не надо передёргивать :-D
если работа идет в конторе, где "за даунтайм закопают", то и сетевушки там все одной модели.
...
и не только.
>если работа идет в конторе, где "за даунтайм закопают", то и сетевушки
>там все одной модели.Не видел контор где бы заморачивались сетевушками одной модели если честно.Хотя наверное бывает и такая параноя, но это уже совсем жесткач =)
Хотя для совсем параноиков я могу придумать схемку и пожестче чем вон там внизу с OpenVZ, но мне кажется что с такой параноей вопрос сведется в основном к тому к кому первому придется вызывать крепких чуваков в белых халатах - к хаксору или к админу :)
>Не видел контор где бы заморачивались сетевушками одной модели если честно.Хотя наверное бывает и такая параноя, но это уже совсем жесткач =)да не вопрос. покупая сетевушки на какой-нибудь очередной маршрутизатор, web-сервер и т.д. прикупить ещё одну. :-)
или после того как что-то сдохнет Вы предпочитаете бегать в ближайший магазин?
резерв должен бытьк тому же дрова как правило поддерживают целый ряд моделей. т.е. надо просто знать какую модель купить.
>>если работа идет в конторе, где "за даунтайм закопают", то и сетевушки
>>там все одной модели.
>
>Не видел контор где бы заморачивались сетевушками одной модели если честно.Хотя наверное
>бывает и такая параноя, но это уже совсем жесткач =)
>Крупная компания с централизованными поставками будет покупать только одну модель для серверов - проверенную.
>>если работа идет в конторе, где "за даунтайм закопают", то и сетевушки
>>там все одной модели.
>
>Не видел контор где бы заморачивались сетевушками одной модели если честно.Хотя наверное
>бывает и такая параноя, но это уже совсем жесткач =)
>Вам не повезло.
Корпоративный стандарт в отношении покупки техники одного производителя очень поможет, если где-то что-то не дай Бог вылетит.В части сети запасные маршрутеры пару раз выручали.
PS Ядро - монолит. Все что возможно - продублировано. Это не паранойя - это деньги.
> Вам не повезло.А может, наоборот? А то с таким уровнем паранои и ответственности можно ведь и с катушек слететь. Или схватить инфаркт если что-то где-то все-таки упадет.
>> Вам не повезло.
>
>А может, наоборот? А то с таким уровнем паранои и ответственности можно
>ведь и с катушек слететь. Или схватить инфаркт если что-то где-то
>все-таки упадет.с катушек слетают как раз те, которым в интересный момент нужную деталь заменить не чем. :-D
особенно интересно наблюдать за их суетой, поездкой в магазин, покупкой дерьма (ибо по закону Мерфи именно в этот момент ничего "нормального" нет), потом установкой этого дерьма, потом убиранием оного (ибо оно на то и дерьмо, чтобы не работать),..... (тут пошла рекурсия :-D).....
и в лучшем случае это заканчивается литром водки :-D
>Всегда,когда собираю ядро для сервера отключаю модули вообще)Если кому понадобится - вкомпилят и этот модуль в ваше ядро
ха. 3-и раза :-D
>Если кому понадобится - вкомпилят и этот модуль в ваше ядроНу да, и внеплановую перезагрузку совсем никто не заметит... особенно параноики которые модули отключают :)
>Всегда,когда собираю ядро для сервера отключаю модули вообще)А когда апдейты выходят, вы ядро пересобираете, да?
У меня больше десятка серверов, я делаю
apt-get update
apt-get upgradeа вы как?
Я, например, делаю локальный репозитарий, а туда уже можно и свой собранный пакет ядра положить.
>Всегда,когда собираю ядро для сервера отключаю модули вообще)А что если вспомнить что у нас год 2008 на дворе?Можно и покрасивее ведь изгальнуться :)
Берем OpenVZ.Режем жирную физическую машину на кучу менее логических серверов.Можно скажем по принципу "каждому сервису - свой контейнер!".
В итоге...1) Слом VDS-машины еще не пиндык.Модули там загрузить из guest системы нельзя :P.А host вообще не обязан быть хакеру доступным по сети.Пусть галимных guset-ов ломают :)
2) Если сломали FTP сервер - сломали только FTP сервер.Ничего сверх этого хацкер не приобретет.
3) DoS атаки на ресурсы?Хаха, попробуйте!Эта штука может резать CPU, диск и прочее по квотам.Сначала виртуалку отполисует тамошний шедулер а только потом уже будет определяться какому процессу виртуалки сейчас работать.И так со всем.Так что захавать все ресурсы при должной настройки не выйдет.Как и создать другим контейнерам проблемы, ибо разделение ресурсов - на уровне.Зато можно гарантировать некий минимум всем контейнерам.Тогда сервера всегда получат достаточно процессорного времени чтобы как-то шевелиться, независимо ни от чего.
4) Можно слить состояние машины в файл.
4а) В случае проблем можно это состояние раскатать.Одним чихом откатив все несимпатичные изменения за считатнные минуты.
4б) Или можно смигрировать машину в файле на другой хост и восстановить ее там.В идеале даже сетевые соединения не порвутся - для всех будет видно только что машина немного притормозила.А то что ее при этом слили в файл, перенесли на другую железку и запустили уже там - известно только админу железки.Так можно при нужде вообще потушить железку не гася виртуальные машины.
5) Если долбит параноя - я бы подумал о расставлении капканов для раннего обнаружения хакеров :).Например можно попробовать что-то типа недавнего монитора ФС прикрутить.Если удастся такое раскидать на VDSах, мониторить их по принципу 1 контейнер на сервис - несложно.В том плане что весь доступ к файлам контейнера из-за этого заранее почти железобетонно известен.Хацкер немедленно спалится на незапланированном доступе к файловой системе :).Тут уже на выбор - можно машину с ним погасить автоматически, заалертить админа и прочая :)Вот такая системка хакерам не понравилась бы имхо.И не поймешь что сломал виртуалку пока не поэкспериментируешь, а когда поймешь - админу уже аларм уедет а то и вовсе виртуалку загасит скрипт засекший доступ которого быть не должно :)
красива...кста, ванилла нонче уже вплотную подходит к опысанным вами фичам OpenVZ
(сами же московские ребята туда и шлют свои VZ патчи ;). Вот тока пока
по лимитам на I/O дисков ниче не слышно в ванилле...
>DoS атаки на ресурсы?Хаха, попробуйте!вам ниразу порт не забивали? везет...
>>DoS атаки на ресурсы?Хаха, попробуйте!
>
>вам ниразу порт не забивали? везет...Тут какбэ говорят об атаке на ресурс машины, а не об атаке на пропускную способность канала. Вообще от любого DoS'а в общем случае защиты нет.
а чем сетвуха не ресурс машины? канал не обязательно забивать если он гигабитный, а сетевуха стомегабитная.>Вообще от любого DoS'а в общем случае защиты нет.
это какой такой общий случай?
>а чем сетвуха не ресурс машины? канал не обязательно забивать если он
>гигабитный, а сетевуха стомегабитная.
>
>>Вообще от любого DoS'а в общем случае защиты нет.
>
>это какой такой общий случай?Вы не понимаете оборота речи "общий случай"? Учите русский язык.
В большинстве случаев техническими средствами нельзя преодолеть последствия DoS-атаки. Какие-то технические решения могут лишь снизить эффект от воздействия, могут устранить побочные эффекты (влияние на не находящиеся под атакой сервисы или ресурсы), но универсального технического решения нет. Можно только найти тело, организовавшее атаку, и открутить этому телу голову.
>вам ниразу порт не забивали? везет...Под DoS атакой на ресурсы имелось в виду например:
- Нагрузить проц на максимум, чтобы остальным процессам почти не досталось времени.Имеючи рута можно своим процессам такой приоритет вбубенить что остальное будет сурово сосать, ожидая пока подачка в виде кванта процессорного времени перепадет.Этим остальным может оказаться и ssh например, так что если вдруг сервак не у админа под задом, контроль над оным окажется на некоторое время утерян.
- Забить диск, чтобы все остальные сервисы получили все шансы пообломаться.Будучи рутом традиционно можно засрать диск под ноль.Но только в случае такой вот виртуалки под ноль выжрется сугубо ее дисковая квота, на чем все и закончится....А остальное на той же железке не заметит никаких проблем :)
- Выжрать всю оперативку, загнав систему в жестокий своп или даже совсем выюзав память.
- ...Кстати все это может произойти и без злобных хакеров.Из-за административной ошибки, например.
В случае предложенного подхода будет не ситуация "Алло! Сдох наш крутой сервер со всем что там было!Нам надо срочно его перезагрузить!Нажмите пожалуйста на нем reset!" а всего лишь одна несчастная виртуалка с одним сервисом впавшая в ступор.При том ступор - это не трындец всему большому крутому серваку.А в самом плохом случае всего лишь потребление максимально разрешенных для виртуалки ресурсов, остальные сервисы в соседних виртуалках в такой ситуации вообще не заметят что что-то не так.А перезагрузить такую виртуалку можно вообще программно, силами админа, etc.
если случилось что-то жесткое на сервере, имеется мониторилка и админ не ротозей, то в большинстве случаев, если ssh умерло, отца русской демократии спасет КВМ, и кнопку reset жать совсем не обязательно, на худой конец можно и ктрл+альт+делитом обойтись из той же КВМ. Ну да это все не важно...
Как вам представляется такое: серверу выделен один ip и на этом ip должно висеть несколько сервисов каждый из которых заключен в свою виртуалку? НАТ городить?
кстати во фре некоторые проблемы ресурсов решаются чтением man login.conf
>Как вам представляется такое: серверу выделен один ip и на этом ip
>должно висеть несколько сервисовтипичная ситуация
>каждый из которых заключен в свою виртуалку? НАТ городить?Линуховые cgroups: можно шарить или разделять как ресурсы, так и сетевой
namespace.
Так вот в этом случае сетка может остаться одна, а вот по ресурсам
(проц, память и т.д.) порезать каждый сервис в свою песочницу.
Порты все слушают на одном ИП, а выполняют запросы за счет своих лимитов.
>кстати во фреах да.... %) понятно
так мы же о OpenVZ?
>так мы же о OpenVZ?пардон, конечно, что влез не в свой спор.
Я увидел, что речь о вируталках. Ну дык cgroups уже практически догоняет OpenVZ
(это, собсно, их же патчи, принятые в ваниллу). За сим, да, мы и об OpenVZ
тоже, его ванильной реинкарнации :)
>если случилось что-то жесткое на сервере, имеется мониторилка и админ не ротозей,
>то в большинстве случаев, если ssh умерло, отца русской демократии спасет
>КВМ,КВМ - имеется в виду консольный свич чтоли?А если я при этом в N км от сервера, как он меня спасет то?В случае с OpenVZ есть возможность дать пинка проблемной виртуалке его средствами, в частности это возможно сделать и удаленно при желании(разумеется позаботившись о том чтобы хаксоры этого сделать не могли).При том как уже замечалось - при этом стоит колом только 1 конкретная виртуалка, хавая в наихучшем случае всего лишь максимум ресурсов позволенный квотами.Остальные сервисы на соседних виртуалках даже не заметят что что-то не так.
>и кнопку reset жать совсем не обязательно,
>на худой конец можно и ктрл+альт+делитом обойтись из той же КВМ.Будучи root'ом можно настолько забить систему задачами (например поразвлекавшись их запуском с реалтаймным шедулингом или ренайсом) что заколебетесь окончания шатдауна ждать.Что до ремотного управления - бывают еще IP kvm - но они стоят достаточно ощутимо бабла, есть не везде и прочая.Поюзать OpenVZ можно на почти любой железке и это ничего не стоит.А в паре с такими решениями управляемость и надежность еще больше улучшится.
>Как вам представляется такое: серверу выделен один ip и на этом ip
>должно висеть несколько сервисов каждый из которых заключен в свою виртуалку?
>НАТ городить?Можно.А в чем проблемы то?
>кстати во фре некоторые проблемы ресурсов решаются чтением man login.conf
Ну, так можно сказать и про ulimit'ы всякие. Только на фоне фич OpenVZ это все как-то блекло, уныло и банально. И ограничений вагон. А стойкость всего этого от саботажа рута под вопросом.То есть конечно можно нагородить пачки костылей, которые иногда даже может быть от чего-то там и помогут.А можно и не извращаться, просто поюзав готовое довольно изящное решение.Оно может и не во всех ситуациях супер-рулез.Но во многих - удобно и практично а предоставляемая фичность порой является тем о чем я несколько лет назад мог только мечтать.
>Будучи root'ом можно настолько забить систему задачами (например поразвлекавшись их запуском с реалтаймным шедулингом или ренайсом) что заколебетесь окончания шатдауна ждатьтак и не надо подобные эксперементы на продакшене проводить, к чему это?
>Можно.А в чем проблемы то?
да даже не знаю в чем, конкретно ответить не могу, какое-то внутренее сопротивление, если желаете - мое чувство эстетики не позволяет :). Хотя с другой стороны выглядит даже лучше, к примеру можно унести на другую машину один из сервисов. И все равно не понятно как этим рулить, многие сервисы взаимосвязаны, к примеру если разносить днс и апач, то при добавлении нового сайта нужно его и в днс-ах прописать, как это сделать автоматом на разных виртуалках и/или тем более, если виртуалка с днс унесена на другую машину? городить какое-то удаленное управление - очередная дыра... как следить, обновлять, проверять софт, если на каждой виртуалке будет свой набор ПО, на машине у вас будет с десяток виртуалок, и машин штук десять, т.е. увеличиваются трудозатраты по поддержанию софта в актуальном состоянии... ну, это так... мысли в слух
КВМ именно что IP KVM. Под боком если сервер имеешь, то клаву к нему обычно не составляет труда подключить, а удаленно без КВМ-ки работать бывает не реально, стоят они не так уж и дорого: ~15т.р., сейчас я общаюсь с этой: http://www.dlink.ru/products/prodview.php?type=30&id=584, с этой: http://www.aten.ru/support/artview.php?idx=125 и переодически еще с квм от американ трендс (цифирки ее так не помню)
Гм,а почему собственно жаль?
Вся функциональность в загрузочном образе,руткиты малореальны,а флешки и я в сервера не тыкаю)
печально это на самом деле. Мне представляется что по мере роста популярности линукса количество подобного ПО будет только расти, и мечта о системе без вирусов/руткитов/спайваре тает с каждым днем.
Отсюда вывод работать надо за наименее распростаненной системой, в свое время таковая была os/2, сейчас это пожалуй *bsd... Лучшее враг хорошего.
>печально это на самом деле. Мне представляется что по мере роста популярности
>линукса количество подобного ПО будет только расти, и мечта о системе
>без вирусов/руткитов/спайваре тает с каждым днем.
>Отсюда вывод работать надо за наименее распростаненной системой, в свое время таковая
>была os/2, сейчас это пожалуй *bsd... Лучшее враг хорошего.если в фуррифоксе уязвимость в жабоскрипте позволяет выполнить код от пользователя, то неважно какая ОСь на той стороне стоит, все равно ssh-ключики и прочие вкусности можно будет без труда угнать
или мусье не в курсе о вреде security by obscurity для ума администратора?
>печально это на самом деле. Мне представляется что по мере роста популярности
>линукса количество подобного ПО будет только расти, и мечта о системе
>без вирусов/руткитов/спайваре тает с каждым днем.
>Отсюда вывод работать надо за наименее распростаненной системой, в свое время таковая
>была os/2, сейчас это пожалуй *bsd... Лучшее враг хорошего.ты слегка дурак. руткит можно написать для любого ядра. рабочих вирусов для линукс нет до сих пор. не стоит путать теплое с мягким.
>Отсюда вывод работать надо за наименее распростаненной системой,Эффективнее на нераспостраненной архитектуре тогда уж.А то x86 хаксоры всяко в момент колупают.Хоть там какое ядро.Достаточно на макось посмотреть - пока она была на PowerPC - хоть бы кто багу нашел.А как только ее перенесли на привычный хацкерам x86 - дыры, трояны и прочие радости посыпались как из рога изобилия.
Но все это лишь усложнит задачу, подняв планку (хацкеру придется скорее всего самостоятельно писать эксплойт и руткит под вашу архитектуру) а вовсе не отменит возможность(если есть что эксплойтить - значит есть).
Ну так по любому можно поламать с root доступом,
главное чтоб нельзя было без онного $^.
>Ну так по любому можно поламать с root доступом,Ламают обычно ламеры.Остальные ломают :P
Господа, что за детский сад - вредоносное ПО будет всегда и на любых ОС. А создателям данного руткита надо быть благодарными за то, что они вскрыли эту проблему.
+1
а если внимательно прочитать, то можно сделать вывод, что такую штуку можно сделать для любой ОС всем известной платформы.и благодаря этим ребятам разработчики линух предупреждены. а вот что будут делать остальные?
>такую штуку можно сделать для любой ОСSoftice чтоли? Механизм отладки ядра прост как дерево, записать во все отладочные регистры нули и руткит летит ко всем чертям. Ловушки определяются по таблице дескрипторов. Не уверен есть ли вывод донной информациии в /sys /proc если нет, можно добавить. Или свой модуль вкомпилить, обнуляющий оотладочные регистры и отслеживающий GDT и таблицы страниц.
Softice?
прям ностальгия какая то... :-)
...
у них даже listener IIS на уровне ядра работает. Или вы всерьёз верите, что винда - это действительно микроядро?
нда.. был опыт работы с DDK... :-)
>верите, что винда - это действительно микроядро?Оно такое же микро как и микрософт.То есть, даже если там и есть что-то от микро, в любом случае это непременно будет king size :)))
>Оно такое же микро как и микрософт.То есть, даже если там и
>есть что-то от микро, в любом случае это непременно будет king
>size :))):D
<jupi>
>Господа, что за детский сад - вредоносное ПО будет всегда и на
>любых ОС. А создателям данного руткита надо быть благодарными за то,
>что они вскрыли эту проблему.Сам в сад иди. Эта утилита работает только с правами root.
Спросите для чего она нужна - а нужна для того, чтобы показать, что IA-32 не совершенна (в принципе это давно всем известно ;-) ) И показать какие подводные камни надо обойти.Так что утилита - вовсе не вирус, а всего лишь толчок к совершенствованию безопасности ядер ОС, работающих на IA-32.
>современных процессоров (IA32)Это тухлое уродство они называют современными процессорами???
>>современных процессоров (IA32)
>
>Это тухлое уродство они называют современными процессорами???Это "тухлое уродство" - процессор х86 по классификации Intel.
Он стоит на 70% современных десктопов.Есть еще вопросы?Ниче, сколько ни кричали про линукскапец, че-т и в этот раз придумаем)
х86 по программированию и структуре в общем мире признан как самы сложный процессор, в отличие от процессоров с конвеерной системой обработки команд(SPARC),,,, Вы спрев раз беритесь с ним как программист - потом кричите, что это урод, - хотя я вижу ту очень много "малышей-крикунов".A Backdoor's - ни в коем случае не показывает слабость процессора, а посказывает уязвимость ОС
> х86 по программированию и структуре в общем мире признан как самы
>сложный процессор, в отличие от процессоров с конвеерной системой обработки команд(SPARC),,,,
>Вы спрев раз беритесь с ним как программист - потом кричите,
>что это урод, - хотя я вижу ту очень много "малышей-крикунов".Крикун здесь один - Вы. Самый сложный - это не достоинство, а недостаток вообще-то. Процессоры попроще жрут меньше электроэнергии, под них проще делать компилятор, под них проще делать конвейерную обработку команд, у них меньше ошибок. Они быстрее компилируют программы и генерируют более качественный код, поскольку оптимизаторы кода для них явно проще.
Начиная с 486 процессора количество ошибок в реализации процессоров архитектуры x86 растёт как снежный ком: http://www.google.ru/search?q=%D1%83%D1%...
>A
>Backdoor's - ни в коем случае не показывает слабость процессора, а
>посказывает уязвимость ОСНеправильная реализация некоторых инструкций процессоров ставит под угрозу ВСЕ ОС, работающие на нём! В данном случае это уязвимость ОС, но проявляющаяся только на x86, из-за особенностей конкретного процессора. Ваше заявление в корне не правильно.
он сложный не потому что у него ОЧЕНЬ большая функциональность.
а потому, что пришлось кучу костылей сделать...
а то бы так и сидели в режиме x86 (или Вы про него и говорили?:-DDD)
> Это "тухлое уродство" - процессор х86 по классификации Intel.
> Он стоит на 70% современных десктопов.Есть еще вопросы?С каких это пор распространённость процессора (или др.устройства) коррелирует с его совершентсвом/отстойностью? Распространённость определяется маркетингом, а вовсе не техническими характеристиками!
>Это "тухлое уродство" - процессор х86 по классификации Intel.
>Он стоит на 70% современных десктопов.Есть еще вопросы?Да никаких вопросов - всем давно известно что далеко не всегда технически лучшее решение одновременно и наиболее маркетингово успешное.Дерьмовость архитектуры Win9x не мешала продажам, знаете ли.Зато потом как бонус можно было каку закопать, продав уже NT-based честно рассказав какое вон то было дерьмо :).Интель в свое время с итаниумом обломался и потому продолжает снабжать x86 уродца костылями.Не потому что он такой хороший, а потому что интель умеет именно это делать конкурентоспособно.
Береги ядра с молоду
>Береги ядра с молодуЗначит надо проверять систему в chroot окружении, на другом (проверенном :)) ядре.
Я так понял что придуман просто новый способ скрывать трояны, которые нужно запускать как обычно с праваи рута?В следующей версии он будет еще более скрытым\в ледующей версии ядра это исправят, и пиар этой компании умрет также как и способ скрытия процессов ?
в следующей версии он не будет экспортировать символы, по которым его можно вычислить сейчас.
>в следующей версии он не будет экспортировать символы, по которым его можно
>вычислить сейчас.ну дак а брешь по которой он работал тоже прикроют и получистя что очередная сказака "были вирусы, были когдато..." это же опен сорц
нормально. пусть лучше вскрывают проблемы и решают их,
чем потом сервера будут падать или еще чего...
>нормально. пусть лучше вскрывают проблемы и решают их,
>чем потом сервера будут падать или еще чего...Ну нельзя же так вестись на подобный бред. Это никакой не метод - это штатные возможности отладки IA32. Нет никаких проблем и никогда не было.
приколись, любой вирус/руткит/бэкдор/троян/etc использует штатные возможности процессора :)
>приколись, любой вирус/руткит/бэкдор/троян/etc использует штатные возможности процессора :)Ну с дебаговыми регистрами - это все-таки уже наглеж :).Наглее пожалуй только сделать троянский гипервизор, который вообще пожалуй хрен заметишь :)
>>приколись, любой вирус/руткит/бэкдор/троян/etc использует штатные возможности процессора :)
>
>Ну с дебаговыми регистрами - это все-таки уже наглеж :).Наглее пожалуй только
>сделать троянский гипервизор, который вообще пожалуй хрен заметишь :)Кстати, если мне не изменяет память, это уже делали.
А сама идея была высказана сразу же, как только в х86 появилась поддержка виртуализации :-)
>А сама идея была высказана сразу же, как только в х86 появилась
>поддержка виртуализации :-)Интелю оно даже понравилось и они заимплементили - vPro по сути нечто подобное и есть, особенно с точки зрения юзера.
ЕМНИП именно так и работают современные дебагеры на вин на x86.так что они там "изобрели"?
похоже в одной лодке плывем:D
ну что тут можно сказать... пользуйте монолитные ядра по возможности...
боевые хомячки убиваются апстены, остальные отлично понимают, что для загрузки модуля ядра нужны права рута. а если кто-то вломился под рутом, то тут уже фиолетово, всё равно вся security сдохла.итого: буря в стакане. причём стакан даже без воды.
да дело то даже не в этом!
на линухе эта техника разрабатывается и обкатывается...
а эксплуатироваться будет на других. :-D
>да дело то даже не в этом!
>на линухе эта техника разрабатывается и обкатывается...
>а эксплуатироваться будет на других. :-Dа на других мне как-то плевать. %-)
алсо, если бздёвники думают, что для их бзди такое сделать сложнее, то они крупно ошиблись.
а ещё всем нервным советую поискать в сети по словам blue pill.
>алсо, если бздёвники думают, что для их бзди такое сделать сложнее, то
>они крупно ошиблись.sysctl kern.securelevel=1 или выше.
О! :) ещё один свято верящий в это :)))))
смотрим сюда:
http://www.opennet.me/opennews/art.shtml?num=17713если злоумышленник выполнит код в контексте ядра, но будет уже поздно.
>боевые хомячки убиваются апстены, остальные отлично понимают, что для загрузки модуля ядра
>нужны права рута. а если кто-то вломился под рутом, то тут
>уже фиолетово, всё равно вся security сдохла.
>
>итого: буря в стакане. причём стакан даже без воды. интегрироватьесли кто-то вломился под рутом - то он не обязательно будет делать rm -rf /*, или совать в motd "админ - элтон джон". ему может понадобится оставить на сервере мааленькую тулзу которая рассылает нимножка спама, тырит нужные данные или еще какую каку делает. так что новый метод сокрытия нехороших процессов - очень даже пригодится таким дядькам.
бесспорно Вы правы. :-)
но вот лично я уже предупреждён об это методе под линух.
...
а вот как это будет выглядеть на других платформах? :-)
некоторые подозрения у меня уже есть конечно, тем более, что в ряде ос недавно добавили продвинутые технологии отладки,... :-D
>если кто-то вломился под рутом — то он не обязательно будет делать
>rm -rf /*, или совать в motd «админ — элтон джон».
>ему может понадобится оставить на сервере мааленькую тулзу которая рассылает нимножка
>спама, тырит нужные данные или еще какую каку делает. так что
>новый метод сокрытия нехороших процессов — очень даже пригодится таким дядькам.а какая разница? однозначно админ там мудак, не всё ли равно, как маскироваться? если система не орёт благим матом, когда кто-то логинится под рутом, то хоть плакат a0 вешай «здесь был хакир» — не заметят.
>ему может понадобится оставить на сервере мааленькую тулзу которая рассылает нимножка
>спама,А на кой хрен для этого вообще сдался рут?С рутом можно замаскировать эту активность, скажем, руткитом.
>боевые хомячки убиваются апстены, остальные отлично понимают, что для загрузки модуля ядра
>нужны права рута.Да, но вот только если это все-таки случится, хаксора выбить с машины будет не так то просто уже.Впрочем непросто будет и просто засечь его наличие.В любом случае нахождение и обезвреживание хаксора с руткитом куда сложнее чем хаксора без руткита.Хорошо что в линуксе есть чем ответить на эту угрозу - всегда можно озадачить хаксора богатым набором нестандартных приколов, а пока хаксор будет просто разбираться что за фигня - у него будут все шансы спалиться :)
Скоро в биосе появится линукс, из которого можно будут под OpenVZ запускать систему. И хрен кто железный линукс поломает.
В принципе идея с DRx на платформе x86/x86_64 известна еще с лохматых годов.
С этой фишкой полиморфные вирии были еще под DOS :)Правда для достижения этой идеи, процесс пишущий.читающий DR должен быть в нулевом кольце защиты процессора.
Сдается мне скоро появится антируткит к этому руткиту, который будет встроен в ядро и будет чекать эти самые Debug Registers и отсылать всех пытающихся в них писать в сад.
Да и дебаг-регистров не так-то и много, всего 8 штук особо не разгонишься, а на амд64 в 64-х битном режиме при попытке записи в эти регистры вылазиет эксепшн GPF так-что фуфлыжный руткит какой-то:)
теперь ещё и поддержка аппаратной виртуализации появилась...
rootkit подобного вида был выпущен ещё 2 года назад.
Руткит не делал, но о возможности фарсить через отладочные регистры узнал ещё 10 лет назад...
скрытые процессы?
|-)а как же старый добрый kill -0 PID
http://packetstormsecurity.org/UNIX/penetration/rootkits/r57...
Скорее всего руткит юзает MSR в купе с DR. Я уже когда то писал, что фактически под давлением M$ интел наворотила неявные команды через управление MSR. Ясно дело, постепенно информация утекала, где то хакеры помогли, но постепенно с механизмом защиты kernel от реверинжиниринга через манипуляции MSR начали разбираться. Ясно дело что спецы забугорные, инфы мало. Хотя наш Крис Касперский вроде в курсе этих телодвижений. В общем как только проблема руткита станет действительно актуальна, ядру сделают иммунитет. В конце концов, достаточно сделать чтение MSR через proc, а далее написать SED сигнатуры допустимости и иметь сигнатуры запрещения. Но наверняка мантейнеры ядра найдут способ эффективнее.
По крайней мере сейчас для лина 100% способ избежать подобного - собирать ядра без поддержки модульности. В случае замены/апгрейда аппаратуры - пересобирать ядро. Это конечно при условии, что вы не стянули исходники ядра фиг знает откуда, и не наложили патчей на ядро фиг знает каких.
А вот в винде подобные руткиты это полная засада. Поговаривают про дорогую базу "умных" сигнатур, которая описывают поведение участков кода ещё не вышедших руткитов и вирей. Могу представить такую базу у спецслужб :)А вообще мечтается о взрослении архитектуры ARM хотя бы до уровня настольной, или опускание с небес на землю процов от IBM, SUN... Но, скорее всего, это уже далеко за вопросами рыночной стратегии...
1. Монолитность ядра (без модулей)
2. RO Раздел для ядра. В идеале диск CD.
3. Виртуальные машины круто но перед большими нагрузками не актуально (опустим).
4. Не допускать запуск приложений от root.
5. Тотальный контроль FS.
6. Honeypot никто не отменял.
7. Не допускайте к серверам случайных особей ;-)
> 1. Монолитность ядра (без модулей)Если вылетит какая-то железка, а аналогичной не будет - об этом можно и пожалеть при случае.Более того, если однажды окажется что надо бы еще вон тот функционал...
> 2. RO Раздел для ядра. В идеале диск CD.
Вариант.Но как его потом обновлять то?А то вдруг в нем крЮтую багу найдут?Перманентно бажное ядро - это уже скорее подарок хакерам чем усложнение им жизни :).Особенно нехорошо будет если сервером хочется рулить ремотно.Как вариант видится проверить со старым ядром более новое ядро на цифровую подпись Одмина, великого и ужасного и потом в случае успеха kexec на него сделать.Но это как-то геморройно уже.Потребуется много нестандартной handjob и потом поддержка всего этого будет сугубо на плечах админа.Т.е. скажем апдейт ядра будет уже не авто и админу придется самому педалить.Что првда при таком уровне паранои - пожалуй сойдет за плюс.
>3. Виртуальные машины круто но перед большими нагрузками не актуально (опустим).
А нельзя ли обругать OpenVZ с этой точки зрения?Он, зараза, легковесный весьма... хотя конечно ОЧЕНЬ тяжелые нагрузки лучше всяко без каких либо лишних прослоек, кто ж спорит?
> 4. Не допускать запуск приложений от root.
Все замечательно.А как например, порт 80 занять не будучи рутом?Потом то права можно и дропнуть, но...
> 7. Не допускайте к серверам случайных особей ;-)
В зависимости от крутизны оных они могут и самодопуститься, как это например было в случае полисменов vs сервер RazorBack.
>Все замечательно.А как например, порт 80 занять не будучи рутом?man 7 capabilities
они так и не вошли в POSIX
Прочитал новость с удовольствием: Видимо, второй шанс нормальным вирусам и их авторам со времен ДОС даст именно Линукс, и это хорошо, а то эта херня, которую сейчас обыватели вирусами называют, это ж вообще верх человеческой лени, в винде уже, по-моему, нужно "Мастер создания вируса" сделать и примеров тучу - чтобы сразу в дистрибутиве шло. Совсем уже вирусописатели ничерта в программировании не понимают.
>в винде уже, по-моему, нужно "Мастер создания вируса" сделатьВы опоздали - конструкторы вирусов это бойан, а у печально известного пинча помнится для тупых был конфигуратор.