В документе (http://www.nexis.ru/articles/kernelsecure.htm) рассмотрена возможность написания модуля Linux ядра, перехватывающего системные вызовы для скрытия следов взлома. Приведен краткий обзор существующих средств защиты (Chkrootkit (http://www.chkrootkit.org/), Rkdet (http://www.vancouver-webpages.com/rkdet/), LIDS (http://www.lids.org/)).URL: http://www.nexis.ru/articles/kernelsecure.htm
Новость: http://www.opennet.ru/opennews/art.shtml?num=5712
Нда.. все это правда, но немного слабовато для НИИ
Ага, а ссылка на Rkdet приведена вообще старая.. 2002 год
Все об этом говорят, но ни разу не встречал, чтобы сисадмин настолько заморачивался с безопасностью... Интересно, в какого рода случаях приходится ставить LIDS? В случае работы с гостайной??? наверное нет..
Наверное там, где есть несколько админов. НСД к системе так или иначе возможен, если в ней работает сразу несколько юзеров, даже если у них не админские права
>Наверное там, где есть несколько админов. НСД к системе так или иначе
>возможен, если в ней работает сразу несколько юзеров, даже если у
>них не админские праваНет, ну тема безусловно актуальная. Кстати она частично была реализована нашими программерами в МСВС. Это я про мандатную политику разделения доступа, если что :)
МСВС не впечатлил, если честно - какой-то он недоделанный немного, уж извините, отечественные разработчики
>Нет, ну тема безусловно актуальная. Кстати она частично была реализована нашими программерами
>в МСВС. Это я про мандатную политику разделения доступа, если что
>:)AFAIK они взяли это из RSBAC.
не накатывать сервак и контент шесть раз в год из таров гэзэ.Перебой, однако. Теряется пятая девятка.
Воткнись в Сеть няпрямую и узри отчеты snort'a.
Славно трындеть, сидя в виртуале за забором провайдерских сысок.
Но баранам, кстати, и там нет покоя. Я просто ссал кипятком, наблюдая, как скрипт гасил "сереверы" с пэхэпэБЭБОЙ.
Для справки. За 2 суток было угандошено 44000 серверов. И эпидемия была отсановлена только прекращением выдачи результатво поиска Гуглом и Яхой.
мой снорт стал просто с ума сходить, заваливая меня сообщениями, что сайт реферера атакован через "viewtopic.php".Стучу перцу в аську. Спрашиваю тебя ломали? Он говорит да, не накатил вовремя патчи на php сраный BB бл нах. Ну, думаю, ученый вроде, пусть бдит и дальше. Но правило из снорта не затер. Затру, думаю, когда статистика меня успокоит.
И вот оно:
http://www.xakep.ru/post/27186/
http://www.xakep.ru/post/27186/exploit.txtГандошь - не хочу!
Снова стучу в аську. Перц накатывает патч и снорт утихает.
IDS - вещь необходимая. А скольким хорькам я шеллы зарубил на западных хостингах, рапортуя на abuse@ об их сраной активности - ваще известно только моему ACID архиву.
Кстати Snort тут не при чем
Самая лучший материал по настройке LIDS можно читать тут: http://www.linuxrsp.ru/artic/lids.html Если ссылка не работает, то тут: http://dh.opennet.ru/lids.html
>Самая лучший материал по настройке LIDS можно читать тут: http://www.linuxrsp.ru/artic/lids.html Если
>ссылка не работает, то тут: http://dh.opennet.ru/lids.html
Ну не знаю, лучший ли, но довольно полный...Первая ссылка, кстати, не работает.
Хотелось бы поглядеть на этот LIDS, только вот линуха нигде нет :) А есть ли что подобное под BSD?
man mac и дальше по ссылкам. Очень похоже что линуховый Selinux драли акурат с этого (TrustedBSD).
ftp://ftp.chg.ru/pub/FreeBSD/TrustedBSD/README.TXT
Нормально. Если бы писал, наверное, лучше бы не получилось (с учетом того, что я завзятый BDS-шник :-) )
Ограничиваем рута в доступе к файлам. Ну и какой в этом смысл??? Получается теперь, что НИКТО не сможет их править? Или я чего-то не понимаю?
Видимо, root имеет полный доступ к таким файлам только после аутентификации в LIDS.
>Ограничиваем рута в доступе к файлам. Ну и какой в этом смысл???Не только к файлам но и расписываются capabilities,
такие например как CAP_SYS_MODULE (отностильно к данной статье)
или такие capabilities как CAP_NET_BIND_SERVICE
ограничения и разрешения накладываюся на объекты файловай системы
не важно под кем работают процессы под рутом или нет.для доступа к закрытым объектам или изменения объектов только на чтение
возможно при выключении LIDS из терминальной сессии или в глодальном
выключении LIDS.>Получается теперь, что НИКТО не сможет их править? Или я чего-то
>не понимаю?
Получается два суперпользователя: один привычный root, а второй- командир безопасности. Они "борятся" между собой за привелегии: root за файловую систему, а командир - за доступ к процессам.
>>Ограничиваем рута в доступе к файлам. Ну и какой в этом смысл???
>
>Не только к файлам но и расписываются capabilities,
>такие например как CAP_SYS_MODULE (отностильно к данной статье)
>или такие capabilities как CAP_NET_BIND_SERVICE
>ограничения и разрешения накладываюся на объекты файловай системы
>не важно под кем работают процессы под рутом или нет.
>
>для доступа к закрытым объектам или изменения объектов только на чтение
>возможно при выключении LIDS из терминальной сессии или в глодальном
>выключении LIDS.
>Это не только LIDS присуще, в более глобальном вырианте (имхо) проект grsecurity и RSBAC.
Grsecurity, PaX+RBAC и все летят, как фанера над Парижой.
Если только в самом Grsecurity дыр нет, что уже имело место случаться, в общем-то.
Уважаемые авторы и специалисты по безопасности!!! Ответьте все-таки на вопрос: в каких случайх действительно нужна такая защита ядра?? Если кто настраивал, привелите примеры: на чем (функционально) именно?
Идея с модулем забавна :)