Differences between revisions 1 and 2
Revision 1 as of 2008-07-30 05:13:51
Size: 19103
Editor: eSyr
Comment:
Revision 2 as of 2008-07-30 21:46:00
Size: 22213
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Поговорим про обесп. секретности. Речь вт о чём: пск. мы польз. пргр. продуктов, и поск. мы имеем дело с некоей сист., обесп. разд. на субъектов и бъектв, с кторыми эти субъекты могут работать, и работают они на уровне 3, то приобретает значение сам факт того, что некий человек сторонний может всп. ресурсами кмпьютера тем или иным способом. Одним людям мы разр. польз. инт., другим --- нет. Когда мы говрим про огр. доступ, т мы оворим именно про оогр.ю, когда злоумыш. огр. нарушает. Первое, с чего стоит начать, что на каждое отверстие найдётся отвёртка. Если у человека есть возм. развинтить компьютер, то единственное ухищрение --- шифрование диска на урвне контроллера. То есть защита данных на урвне их секретности начинается с адм. стороны, а е с прграммной. В первую чередь, никт не должен иметь доступ к серверу, не длжен иметь доступ к консоли (ввести пароль в лило). Такие вещи начинаются именн с защиты на адм урвне. Поговорим про обеспечение секретности. Речь вот о чём: поскольку мы пользуемся различными программными продуктами, которые имеют разные уровни доступа к разным объектам системы, было бы неплохо сделать так, чтобы процессы какого-нибудь случайного пользователя системы не навредили нашим объектам. Одним людям мы что-то разрешаем, другим --- нет.
Первое, с чего стоит начать, что на каждое отверстие найдётся отвёртка. Если у человека есть возможность развинтить компьютер, то единственное ухищрение --- шифрование диска на уровне контроллера. Защита данных на уровне их секретности начинается с административных мер, а не с программных. В первую очередь, никто не должен иметь доступ к серверу, не должен иметь доступ к консоли (вспомним init=/bin/bash). Такие вещи начинаются именно с защиты на административном уровне.
Line 5: Line 6:
Поднимаясь на урвень выше, начинаем говорить пр ур. программный. При входе запр. его credentials, когда он работает в сети, там тоже такие вещи, и так далее. что касается защ. данных от произв. доступа, то лектору кажется, чт в юних подобных системах это решено более-менее ... способом: есть правдадоступА, и если приняты действия по томУ, чтобы нельзя эти права нарушить, то всё хорошо. Надо единственное следить, чтобы права были правильные. Поднимаясь на уровень выше, начинаем говорить про уровень программный. Вобщем-то, в юникс-подобных системах весьма неплохо сделана система разграничения прав, и если права выставлены грамотно, и нет возможности их нарушить (система достаточно надёжна) --- то всё хорошо.
Line 7: Line 8:
Кстати очень многие службы не стартуют, если секретные данные доступны не только службе и руту. К счастью, есть такая штука, как umask, которая указывает, какие права будут убваться при созд. файла. Кстати очень многие службы не стартуют, если секретные данные доступны не только службе и руту. К счастью, есть такая штука, как umask, которая указывает, какие права будут убиваться при создании файла (к примеру, umask 022 означает снятие бита записи в группах доступа g и o, то есть права вида 755).
Line 9: Line 10:
Нелишне помнить, что говоря о надёжности систеы, мы воорим в тм числе об атаках на тказ в обслуживании. Тг есть, сказали чт-т сервису, и он взял и упал, кгда мы гворим о том, чт адм. должен обесп. файлов, мы забываем, чт у ОС есть ещё два ресурса: п. память и прц. время. И то, и др. мжет быть яблоком раздора среди польз., и плоьз. мгут захотеть заглотать его таким способом, чтобы другие не смогли ничего сделать. В линуксе нельзя одним процессом, если он не рутвый, всё время съесть. Но есть ещё ресурс количества прцессов: если вы хотите пожрать проц. время, т ваша задача запуситьт как можно больше прцессов Нелишне помнить, что говоря о надёжности системы, мы говорим в том числе об атаках на отказ в обслуживании. То есть, сказали что-то сервису, и он взял и упал, когда мы говорим о том, что необходимо обеспечивать разграничение прав в системе, мы забываем, что есть ещё такие ресурсы, как оперативная память и процессорное время. И то, и другое при удачном стечении обстоятельств может быть съедено в достаточной степени для того, чтобы система перестала работать в штатном режима. В линуксе нельзя одним процессом, если он не рутвый, всё время съесть (ограничения приоритета --- его нельзя повысить, если ты не рут, только понизить). Но есть ещё ресурс количества процессов, принадлежащих одному пользователю: если вы хотите пожрать процессорное время, то ваша задача запустить как можно больше процессов.
Line 11: Line 12:
Сейчас лектор покажет, как это регулируется: ulimit. man limits.conf. Есть штука, которая пзв. эту ситуацию предотвратить. view /etc/security/limits.conf . Это можно привязать как к польз., так и к группе. братите внимание, чт лимиты эти явл. частью окр., из шела оно добывается в ulimit, при логине эти лимиты вменяются, и их нельзя никак улучшить. Когда вы логиничтесь в системе, запускается логин шелл, ему в окр. пропихиваются эти лимиты, и их вы не мжете никак поменять. Разумеется, при ред. этого файла ничего не меняется для запущеннных процессв. Это не свойсто системы, а свойство процесса, обл. функцией ридонли. ## Сейчас лектор покажет, как это регулируется: ulimit. man limits.conf. Есть штука, которая пзв. эту ситуацию предотвратить. view /etc/security/limits.conf . Это можно привязать как к польз., так и к группе. братите внимание, чт лимиты эти явл. частью окр., из шела оно добывается в ulimit, при логине эти лимиты вменяются, и их нельзя никак улучшить. Когда вы логиничтесь в системе, запускается логин шелл, ему в окр. пропихиваются эти лимиты, и их вы не мжете никак поменять. Разумеется, при ред. этого файла ничего не меняется для запущеннных процессв. Это не свойсто системы, а свойство процесса, обл. функцией ридонли.
Line 13: Line 14:
Как броться с форковой бомбой --- прблема в том, пока их убиваешь, они нарождаются. Не исключено, что время вып. скрипта, кторый мы напишем, не убъёт всё. Лучше всего зайти другим польз, хтя можно и этим. Проблема в чём? Аккуратно написанная форквая омба работает быстрее, чем команда kill, и как тольк вы не добьёте хотя бы одну ветку, она экспоненциальн разрастётся. Поэтому эти прцессы надо удивать не сигналом KILL, а сигналом STOP. Тгда они не удаляются из таблицы прцессов и не работают. В данном слчуае очень просто --- killall -STOP ach, после чего killall -KILL ash. Всяческие ограничения, накладываемые на пользовательские процессы, задаются при помощи системы ulimit (полную информацию о том, насколько вас ограничили, можно узнать, сказав шеллу ulimit -a). Параметры записаны в файле /etc/security/ulimits.conf. Ограничивать можно и отдельных пользователей, и группы. Все эти настройки записываются в окружение login shell пользователю таким образом, что не могут быть далее изменены, и, соответственно, наследуются всеми процессами пользователя.

## Как броться с форковой бомбой --- прблема в том, пока их убиваешь, они нарождаются. Не исключено, что время вып. скрипта, кторый мы напишем, не убъёт всё. Лучше всего зайти другим польз, хтя можно и этим. Проблема в чём? Аккуратно написанная форквая омба работает быстрее, чем команда kill, и как тольк вы не добьёте хотя бы одну ветку, она экспоненциальн разрастётся. Поэтому эти прцессы надо удивать не сигналом KILL, а сигналом STOP. Тгда они не удаляются из таблицы прцессов и не работают. В данном слчуае очень просто --- killall -STOP ach, после чего killall -KILL ash.

Весьма популярным способом DOS-атаки системы с плохо настроенным ограничением на число процессов одного пользователя --- так называемая fork-бомба, то есть программа, которая не делает ничего, кроме как с максимальной скоростью порождает собственные копии в больших количествах, в идеальном случае занимая всю память и большую часть процессорного времени. Просто посылать сигналы на завершение работы этой стае напильников совершенно бесполезно, поскольку --- даже если были достигнуты ограничения на число процессов --- как только кто-то умрёт, на их места тут же встанут новые процессы. В принципе, можно попытаться написать собственную форк-бомбу, задача которой --- убивать предыдущую, но скорее всего это только усугубит проблему. Вариант выхода из такой ситуации --- послать всем бомбовым процессам не SIGKILL, а SIGSTOP. Тогда они прекратят своё выполнение, но не будут удалены из таблицы процессов --- они будут всего лишь приостановлены, и их после остановки можно будет легко и просто убить. При возможности управлять ситуацией от лица суперпользователя будет полезно воспользоваться утилитой killall в виде killall -u <имя хулиганящего пользователя> -STOP, и потом killall -u <имя хулиганящего пользователя> -KILL.
Line 35: Line 40:
Лектор забыл упомянуть ещё одну важную вещь, поск. не было разговора пр иксы. Есть отдельный класс подсм. логин под нзванием кейлоггер. Это программа, которая пишет всё, что печатается на клавиатуре. В линуксе есть два места: системная кнсоль, другая штука --- иксы. Когда вы вводите логин-пароль, вы взаимод. xdm, она запускается от рута, и елси кто-то подменил xdm, т он имеет рута, а тут уже какая разница. Даже без локлаьного рута можно легко отдать свои логин-пароль кому-то ни было, если предп. некие действия. Х-сервер работает как неке приложение, которое принимает события с мыши-клавиатуры, и передаёт дальше. Есть wm, который их принимает и раздаёт дальше. Можно написать программу, которая перехватывет их раньше и складывать их куда-то. Эта программа отлжит все нажатия, в том числе логин и пароль. То, что вы можете написать такую программу ... главное, то, что вы можете их запустить. Взхм. запуска пр. методом авторихвации. Первый --- ip-based авторизация. Лектор не советует её включать, пск. может оказаться, что на машине окажется лругой человек. Другой вариант --- исп. MIT magic cookie, xauth, при запуске х-клиент должен дать х-серверу куку, которая лежит в файле, и тут возн. урвень безопаснсти, и при удалённом запуске надо проделать некие телодвижения, чтобы кука оказалась на другой стороне. Есть проблема --- сам по себе X-траффик не шифруется. Лектор забыл упомянуть ещё одну важную вещь, поск. не было разговора пр иксы. Есть отдельный класс подсм. логин под нзванием кейлоггер. Это программа, которая пишет всё, что печатается на клавиатуре. В линуксе есть два места: системная кнсоль, другая штука --- иксы. Когда вы вводите логин-пароль, вы взаимод. xdm, она запускается от рута, и елси кто-то подменил xdm, т он имеет рута, а тут уже какая разница. Даже без локлаьного рута можно легко отдать свои логин-пароль кому-то ни было, если предп. некие действия. Х-сервер работает как неке приложение, которое принимает события с мыши-клавиатуры, и передаёт дальше. Есть wm, который их принимает и раздаёт дальше. Можно написать программу, которая перехватывет их раньше и складывать их куда-то. Эта программа отлжит все нажатия, в том числе логин и пароль. То, что вы можете написать такую программу ... главное, то, что вы можете их запустить. Взхм. запуска пр. методом авторихвации. Первый --- ip-based авторизация. Лектор не советует её включать, пск. может оказаться, что на машине окажется лругой человек. Другой вариант --- исп. MIT magic cookie, xauth, при запуске х-клиент должен дать х-серверу куку, которая лежит в файле, и тут возн. уровень безопаснсти, и при удалённом запуске надо проделать некие телодвижения, чтобы кука оказалась на другой стороне. Есть проблема --- сам по себе X-траффик не шифруется.
Line 48: Line 53:
|| 0 || 1 || 1 || 1 || || 1 || MaximByshevskiKonopko, ОльгаТочилкина, VsevolodKrishchenko || || || || 8 || 1 || 1 || 1 || || 1 || MaximByshevskiKonopko, ОльгаТочилкина, VsevolodKrishchenko || || ||

Безопасность: локальная секретность

Поговорим про обеспечение секретности. Речь вот о чём: поскольку мы пользуемся различными программными продуктами, которые имеют разные уровни доступа к разным объектам системы, было бы неплохо сделать так, чтобы процессы какого-нибудь случайного пользователя системы не навредили нашим объектам. Одним людям мы что-то разрешаем, другим --- нет. Первое, с чего стоит начать, что на каждое отверстие найдётся отвёртка. Если у человека есть возможность развинтить компьютер, то единственное ухищрение --- шифрование диска на уровне контроллера. Защита данных на уровне их секретности начинается с административных мер, а не с программных. В первую очередь, никто не должен иметь доступ к серверу, не должен иметь доступ к консоли (вспомним init=/bin/bash). Такие вещи начинаются именно с защиты на административном уровне.

Поднимаясь на уровень выше, начинаем говорить про уровень программный. Вобщем-то, в юникс-подобных системах весьма неплохо сделана система разграничения прав, и если права выставлены грамотно, и нет возможности их нарушить (система достаточно надёжна) --- то всё хорошо.

Кстати очень многие службы не стартуют, если секретные данные доступны не только службе и руту. К счастью, есть такая штука, как umask, которая указывает, какие права будут убиваться при создании файла (к примеру, umask 022 означает снятие бита записи в группах доступа g и o, то есть права вида 755).

Нелишне помнить, что говоря о надёжности системы, мы говорим в том числе об атаках на отказ в обслуживании. То есть, сказали что-то сервису, и он взял и упал, когда мы говорим о том, что необходимо обеспечивать разграничение прав в системе, мы забываем, что есть ещё такие ресурсы, как оперативная память и процессорное время. И то, и другое при удачном стечении обстоятельств может быть съедено в достаточной степени для того, чтобы система перестала работать в штатном режима. В линуксе нельзя одним процессом, если он не рутвый, всё время съесть (ограничения приоритета --- его нельзя повысить, если ты не рут, только понизить). Но есть ещё ресурс количества процессов, принадлежащих одному пользователю: если вы хотите пожрать процессорное время, то ваша задача запустить как можно больше процессов.

Всяческие ограничения, накладываемые на пользовательские процессы, задаются при помощи системы ulimit (полную информацию о том, насколько вас ограничили, можно узнать, сказав шеллу ulimit -a). Параметры записаны в файле /etc/security/ulimits.conf. Ограничивать можно и отдельных пользователей, и группы. Все эти настройки записываются в окружение login shell пользователю таким образом, что не могут быть далее изменены, и, соответственно, наследуются всеми процессами пользователя.

Весьма популярным способом DOS-атаки системы с плохо настроенным ограничением на число процессов одного пользователя --- так называемая fork-бомба, то есть программа, которая не делает ничего, кроме как с максимальной скоростью порождает собственные копии в больших количествах, в идеальном случае занимая всю память и большую часть процессорного времени. Просто посылать сигналы на завершение работы этой стае напильников совершенно бесполезно, поскольку --- даже если были достигнуты ограничения на число процессов --- как только кто-то умрёт, на их места тут же встанут новые процессы. В принципе, можно попытаться написать собственную форк-бомбу, задача которой --- убивать предыдущую, но скорее всего это только усугубит проблему. Вариант выхода из такой ситуации --- послать всем бомбовым процессам не SIGKILL, а SIGSTOP. Тогда они прекратят своё выполнение, но не будут удалены из таблицы процессов --- они будут всего лишь приостановлены, и их после остановки можно будет легко и просто убить. При возможности управлять ситуацией от лица суперпользователя будет полезно воспользоваться утилитой killall в виде killall -u <имя хулиганящего пользователя> -STOP, и потом killall -u <имя хулиганящего пользователя> -KILL.

Мы позанимались каким-то странным асп. безопасности. Теперь про запретный плод: в этм случае всё, что не запрещ., разрешено хорошоа. Если вы не боитесь ост. в процессе, и готовы быстро восст. при возн. неполадок. И лучше, чтбы дырки и люди были известные, ибо эти люди мтивированы компьютером, и лучше их тлавливать на этом этапе и перевоспитывать.

Более правильно держать процесс под присмотром, и вместо того, чтобы ловить несущ. файлов, следить за существующими. С другой стороны, если жёсткое требвание на учебный прцесс, и если школа, то, взм., эти люди не особ помогут. В принципе, в некторых мат. школах ученики 10 класса могли дать фору многим студентам.

Ещё одно это пароли. Если отоносится к личным учётным записям как к возм. доступа к личной информации, то ... . Известное дело, что утечка идент. инф. приводит к тому, что плучен доступ ко всей инф., которая защищена ею. Стоит иметь в виду, чт прежде чем говорить о такго рода защите, нужно убедиться в том, чт все файлы и так не откр. на чтение раз., никакой возм. (в концепции класса можно иметь свю машину с лок. рутом, потом любым польз. и получить доступ к его данным. Это из того, что у nfs ip-based авторизация, и мы считаем все лок. машины своими) получить доступ в обхд правил. Ещё одна вещь --- хранение файлов на ФС без возм. хранения прав. Возвращаясь к ситуации, когда это соблюдено и нужно уберечь учётные записи от утечки. Снчала следует сказать, что в позиксе давно никаких паролей (авторизационного слова) не хранится. Вместо парля в линуксе хранится хэш. Зайдём в рута и покажем хэш от польз. root. Хэш эт один из видов шифрвания с потерей. Смысл хэша состоит в ом, чтобы сгенерировать дост. большой объём данных, чтбы вероятность свп. двух хэшей была чень низкой, с рйгой стороны, возм. восст. исх .текста по хэщу отсутствовала. И чтобы этот хэш мжн было вычислить из исх. данных. Именно так и происх. прцесс авторизации.

Обр. внимание, чт в отл. от ст. учебников линукс, где написан, что все хэши лежат в /etc/shadow, тут более сложная система, которая взята из архитектуры TCB, в частности, архитектура работы с паролями (tcb). С точик зр. рядового польз. эт выглядит, что у каждог польз. есть свой собст. shadow. Итак, хэш это функц., обл. этими тремя свойствами. Таких функций много. В альте исп. blowfish, в других линуксах md5, в старых юниксах des. Для того, чтобы нельзяб ыло сост. такой техн. индекс (у нас есть пароль, есть хэш), в другом месте другой человек придумал тот же пароль, и у него тогда будет тот же хэш. Чтобы такого не происходило, в исх. включается некий sold(?): $2a --- sold, $08 --- количество применений алгоритма самому к себе. 8-кратное применение работает доли секунды. То есть обычному пльз. не заметно, а перебор затрудняет. Сделано это, чтобы повысить выч. сложность хэша и затруднить перебор. Т. о., когда вы второй раз ввдите пароль, прграммал лезет в shadow, вынимает sold, кол-во вызовов, применяет к паролю с sold'ом функцию необх. кол-во раз и сравнивает хэш.

Лектор возвр. к идеи крипт. пароля, которая, спасиб OWL, в посл. версии заьбита, причём в посл. версии pam-qc, качество пароля настраиваемо. Идея в чём --- чтобы пароль был криптостойкий, нужно всего лишь ... Есть файл /etc/passwdqc.conf, к нему должны ходить программы, проверяющие кач-во паролей. Это часть пам, и все, кто им пользуются, будут его исп. Макс. длина пароля опр. для разл. старых сист. служб. Чуть выше видим параметры минимальной длины пароля для парлей разных видов. Почему такие хитрости, почему не сказать, что пароль должен быть длиннее 16 символов. Это неправда, пск пароль из 16 нулей некриптостоек, если мы подглядели, что польз. давит на одну клавишу. Эти категории паролей отн. к классам символов. Гворя простым языком: если у вас встречаются тольк буквы и цифры или проблеы, т пароль должен быть длинным, поск. букв мало, буквы складываются в лова, а их ещё меньше. Поэтому, если ольз. хчет, чтобы парль сост. из влов, то нужна одна длина пароля. Если польз. согл. исп. маленькие и большие буквы и ни не слова, то парль может быть покороче. Если он готов исп. символы 4 категорий, т пароль может быть ещё меньше. Вт эта надпись,Ю кторую мы видим в конфиге, озн., что 24 символа --- пассфраза из букв двух категорий (два чарактер класса), если готовы запоминать странные символы между ними --- 12, если три категории --- 8, четыре --- 7. Изм. этих настр. ведёт к изм. допустимого ур. безопасности.

В числе прочего не реком. исп. имя польз. как часть пароля,д оно слово и так далее. Всё эт не даст сделать qc, но он не везде включён и для рута он просто выключен.

Руту такие трюки разрешены, будет ворнинг, но всё равно.

Мы видим на экр. усп. обновление пароля.

Какие бывают алгоритмы сост. парлей: строчка из песни, первые буквы чего-нибудь, русские слова англ. буквами, желательно, чтобы там были не тлько англ. буквы, но и э, ж и другие. Пока это работает, хтя леткр предвидит, что вскоре будет искаться и по этому способу. Подбор пароля в противном случае мжет занять доли секунды. Лектору на данный ммент точно неизвестны подборщики паролей, которые ходят по паролям в стиле leet русским. Крме того, там не ольк tr.

Пароли не надо записывать, их надо запоминать. Существуют программы хранения паролей, которые их защищают другим парлей.

Лектор забыл упомянуть ещё одну важную вещь, поск. не было разговора пр иксы. Есть отдельный класс подсм. логин под нзванием кейлоггер. Это программа, которая пишет всё, что печатается на клавиатуре. В линуксе есть два места: системная кнсоль, другая штука --- иксы. Когда вы вводите логин-пароль, вы взаимод. xdm, она запускается от рута, и елси кто-то подменил xdm, т он имеет рута, а тут уже какая разница. Даже без локлаьного рута можно легко отдать свои логин-пароль кому-то ни было, если предп. некие действия. Х-сервер работает как неке приложение, которое принимает события с мыши-клавиатуры, и передаёт дальше. Есть wm, который их принимает и раздаёт дальше. Можно написать программу, которая перехватывет их раньше и складывать их куда-то. Эта программа отлжит все нажатия, в том числе логин и пароль. То, что вы можете написать такую программу ... главное, то, что вы можете их запустить. Взхм. запуска пр. методом авторихвации. Первый --- ip-based авторизация. Лектор не советует её включать, пск. может оказаться, что на машине окажется лругой человек. Другой вариант --- исп. MIT magic cookie, xauth, при запуске х-клиент должен дать х-серверу куку, которая лежит в файле, и тут возн. уровень безопаснсти, и при удалённом запуске надо проделать некие телодвижения, чтобы кука оказалась на другой стороне. Есть проблема --- сам по себе X-траффик не шифруется.

...

Смысл состоит в слеждующем: даже если вы уверены, что если вам за спину никто не глядит, то если вы работаете через сеть с иксами не по ссх, то есть вероятность, что что-то утечёт.


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

8

1

1

1

1

MaximByshevskiKonopko, ОльгаТочилкина, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080729/03LocalSecurity (last edited 2008-10-04 08:11:17 by VsevolodKrishchenko)