LINUX.ORG.RU

Несколько мыслей по безопасности....


0

0

Господа, долгое время патаясь обеспечивать безопасность Linux, пришел к ряду мыслей коими и хочу с Вами поделиться, хочу сразу заметить что всего этого в Linux сейчас нет. 1. Достаточно часто проблемы возникают при атаке на сетевые сервисы(Apache,sendmail,LPR, SSHd, DNS, etc) И получением прав root - т.к. все эти программы работают с правами root, из-за старого, принципа еще Unix кого(80-90), но Linux не Unix, почему бы не отойти от этого принципа и не разрешить любому слушать любые порты, в качестве компромиса(и неплохого), можно предложить определить например файл /etc/rootport.conf (щас его нет), где и перичислить тек пользователей которые на это имеют право и порты, которые они могут слушать. 2.Уже очень часто встречаю мыслю о том, что неоходимо ограничить список программ, которым можно в инет. 3.В ext2 (-> ext3) есть "иммунный бит", запрещающий изменение файла, ссылки, etc., но снять то его можно rootom -спрашивается а какая особо польза - вот если бы снять его можно только с уровня выполнения 1 (сеть off, регистрироваться может только root c вводом пароля!!!.....)- безопасность стала бы лучше. 4. Можно монтировать ф/с ro, но опять таки перемонтировать можно rootom - следовательно и если злоум. получил доступ к консоли (как вариант - Вас срочно вызывают к нач., а вы забываете залочить экран???)-> нужно чтобы mount, passwd, rpm требовали ввода пароля каждый раз при вызове). Естевственно что при монтировании как написано в fstab пароль должен быть ненужен..... есть и еще ряд идей, но как Вы отнесетесь к этим, если найдуться единомышленники, давайте сидеть за ядром.... ВСЕГО ВАМ ДОБРОГО


>сетевые сервисы(Apache,sendmail,LPR, SSHd, DNS)
про апача не знаю нету
sendmail уже не под рутом(хотя так или иначе часть под рутом)
DNS давно не под рутом
LPR просто не юзаю не знаю
sshd хочеш не хочеш но чтоб был рутовый шел должны быть прова рута
кстати у меня sshd висит только на внутренем интерфейсе, так что его с инета
вообще не видно.

>и не разрешить любому слушать любые порты
запросто читать proc.fs

>2.Уже очень часто встречаю мыслю о том, что неоходимо ограничить список
>программ
что подразумевает под собой ограничить ?
удалить их и все

имунный бит на то и имууный но есть еще rsback

>а вы забываете залочить экран
а зачем он сам лочится через пять минуть
а вообще физическая безопастность вам в руки
я и слоком так успею ваш комп разломать(дискеткой и отверткой)

А вообще все это по моему лишнее надо просто почитать внимательнее
факи, да и вообще в доку поперекапывать.

PS:
Для слова сам юзаю пач openwall на ядро, специально оставляю иногда
сервисы с дырой в инет, так для проверки. Chroot на все что видно из инета.
Вообще за то чтоб веб сервер и почтовый сервер жили на разных серверах.
Если вы очень озадачены дырявостью сервисов можно об этом позаботится.
1 убрать прова рута(что не всегда возможно)
2 chroot на сервис
3 использовать пачи аля openwall
4 ставить рсбак
5 есть пачи на gcc для компиляции прог со вставками типа true false на предмет
попыткы переполнения исполнения и чего еще творения со стеком,
производительность проги падает сразу в 10 раз.


А вообще более детально можно поговорить я тоже не против получить дополнительный опыт на мелких заморочках которые совсем рядом просто про них не знаеш. Только пункты более сформулированные и зачем это надо и что
это дает. OK

Aleks_IZA
()

По вашим пунктам, используя имеющиеся стандартные средства (без различных RSBAC & Co):
1. Слушайте на любых портах (в конце концов сделайте DNAT с нужного порта на допустимый), chroot позволяет запускать программы в отдельном пространстве файловой системы, при этом, многие демоны могут запускаться не от root. Apache тоже может не от root бегать (по поводу сообщения AlexIZA). Проблема старая и решенная во многом, IMHO она уже решена, не пугайте новичков, которые тоже тут читают.
2. Только вчера писал - iptables -m owner и ограничивайте сколько хотите по pid, по name (имя процесса), sid (сессия). IMHO проблема решена.
3. После расстановки имунных битов - пересоберите ядро с отключенной возможностью эти биты менять и все. Старое ядро удалить, новое менять биты не даст, сами биты будут действовать. Чтобы переставить биты - перезагрузка с дискеты с полным ядром (возможно это неудобно, можно сделать модульно, хотя тут уже придется что-то серьезно писать). Способ старый, писали про него. IMHO проблема решена.
4. Вот про mount, passwd, rpm даже посмеялся. Ну что вам мешает сделать эти программы симлинками на один ваш sh файл, который и будет спрашивать пароль, а сами программы передислоцировать в другое место с другим именем и зашифровав их, например, по ключу расшифровывать их (или проще - используйте crypto file system и монитуйте ее из файла перед выполнением этих команд, пароль спросите у пользователя). IMHO проблема решаема в принципе различными способами. При загрузке - берите пароль из файла, например.

Вообще сначала надо определиться от кого вы защищаетесь :))) а абсолютной безопасности не бывает, бывает максимум при определенном лимите средств.

saper ★★★★★
()

Абсолютной безопасности может и не бывает, но надо стремиться улучшать то, что есть. В том числе и на уровне системы. Способ "выкрутиться" с симлинками может и сойдет, но улучшить защиту самих системных команд - вполне здравая идея.

anonymous
()

>> но надо стремиться улучшать то, что есть
Не флейма ради - подход неправильный для нормальной компании и даже ее отдельно взятого сисадмина/безадмина (администратора безопасности).

saper ★★★★★
()

IMHO все что отдаляет Linux от UNIX - не здраво само по себе. Линукс существует уже давно, поэтому вполне уже можно было тому же RedHat говорить с промышленными Юникс-гигантами по поводу некоторого общего стандарта, причем не обязательно начинать с документа, называемого ISO в 3000 страниц. Начать можно с малого, тем более хороших широкораспространенных юниксов для того же x86, sparc, alpha, powerpc не так много.

А RedHat not Linux и Linux not UNIX думаю многие уже слышали. IMHO не согласен. Тут конечно не место для обсуждения этого, хотя к теме относится.

saper ★★★★★
()

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

Простой поиск grep immutable по исходникам ядра ничего полезного не дал (
в поисковиках как-то с лету не ищется
забавно
может кто поделится инфой где еденичку переправить в ноль или наоборот
в 2.4

Aleks_IZA
()

ну я сразу по крайней мере 2 места нашел где оно (?) используется:

/usr/src/linux/include/linux/fs.h:#define ATTR_FLAG_IMMUTABLE 8 /* Immutable file */

/usr/src/linux/fs/ext2/inode.c: inode->i_attr_flags |= ATTR_FLAG_IMMUTABLE;

хотя еще и в ext3 не мешало бы его посмотреть....

mator ★★★★★
()

ввиду того, что вопрошавший даже не удосужился прочитать местный FAQ (не говоря уже о посещении www.tldp.org), предлагаю закончить этот бессмысленный разговор.

ivlad ★★★★★
()

Re:Несколько мыслей по безопасности....

Да, господа, спасибо конечно, что прочитали и высказали свои мнения относительно некоторых идей, однако хочу заметить господину oxonian (между прочим это не вопрос, а несколько идей) о том, что как раз чтение всевозможных факов и руководств по безопасности и определенный опыт работы (когда сам себе говоришь а не лучше бы!) привело меня к этим идеям. Да, конечно Linux позволяет многими способами достигать одной и той же цели, но мне (да и многим) хотелось бы реализавать это проще, на уровне ОС- а не перекладывая вопросы безопасности на создателей программ. Да, я знаю что Apache (а такще Roxen, Sendmail, etc...) для оьработки запроса пораждает не root процесс, но слушает то порты он с правами root, это во первых, а во вторых Apache то изменяет ID, а другой какой - нибудь сервис? - получается вся отв. за безопасность перекладывается на программистов серв., а это нехорошо.... да SSHd и другие и следует запускать через xinetd(установив для него interface=xxx.xxx.xxx.xxx), но ведь есть сервисы которые должны быть доступны в инете. Что касается перенапр. на другие порты и т.п. , а помоему проще было бы так, к тому же здесь тоже могут быть ошибки). Да Iptables (хотя я юзаю ipchains) и может огран. по PID, и т.д., ноя здесь имел ввиду защиту от торянских коней и проч.,поэтому неплохо было бы иметь список разреш. программ+ создать контрольные (например MD5) суммы для каждой из них - как например это делает ZoneAlarm в Win32- кстати этот вопрос я очень часто и здесб читал. Что касается имунного бита - думаю что это хорошая идея, но мой метод - разрешить эго менять(снимать) только на уровне выполнения 1 на мой взгяд легче чем загружаться да еще с дискеты (а у меня вообще может не быть floppy да и cdrom на рабочих станциях. Насчет симл. это идея отличная, но не проще ли добавить пару строк кода в программы, благо что исх. доступны, хотя / раждел у меня шифруется по алгоритму 3DES с вопросом пароля при загрузке, а /home с помощью AES - причем пароль береться из файла(для каждого юз. свой файл), зашиврованного GPG,но опять таки это довольно изващенный способ, однаго ведь "много безопасности не бывает" Linux - должна быть совместима с Unix на уровне поддержки стандартов (POSIX,X11,UNIX9x,etc.), однако на мой взгляд она должна улучшать некоторые вещи - как например это происходит с командой TAR - в Linux она к томуже и сжимает.(попробуйте сжать tar в Solaris...)... Еще раз благодарю за высказаные мнения, но всеже попробую реализовать свои идеи посидев над ядром, о том что полкучится обязательно раскажу. ВСЕГО ВАМ ДОБРОГО.....

gdn
() автор топика

Ну да - sandbox - на всех уже сервисах существует. Вот во FreeBSD (с Линуксом работал, но недолго - незнаю) хорошая вешь - Kernel.SecureLevel. Откомпилил систему, установил chflags, поставил securelevel и никакой руут даже ни троянов не запишет, ни изменит.

Собственно- у меня и вопрос к вам - есть ни на Линуксе аналог?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.