Differences between revisions 4 and 26 (spanning 22 versions)
Revision 4 as of 2008-07-31 01:32:01
Size: 28334
Comment:
Revision 26 as of 2008-10-04 11:11:17
Size: 26248
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
== Безопасность: локальная секретность == == Локальная безопасность ==
Line 3: Line 3:
Поговорим про обеспечение секретности. Речь вот о чём: поскольку мы пользуемся различными программными продуктами, которые имеют разные уровни доступа к разным объектам системы, было бы неплохо сделать так, чтобы процессы какого-нибудь случайного пользователя системы не навредили нашим объектам. Одним людям мы что-то разрешаем, другим --- нет. Рассмотрим сначала вопросы обеспечения безопасности локальной работы компьютера, не касаясь вопросов безопасной передачи данных по сети или сетевых атак.
Line 5: Line 5:
Первое, с чего стоит начать, что на каждое отверстие найдётся отвёртка. Если у человека есть возможность развинтить компьютер, то единственное ухищрение --- шифрование диска на уровне контроллера. Защита данных на уровне их секретности начинается с административных мер, а не с программных. В первую очередь, никто не должен иметь доступ к серверу, не должен иметь доступ к консоли (вспомним init=/bin/bash). Такие вещи начинаются именно с защиты на административном уровне. === Доступность: физическая и виртуальная ===
Line 7: Line 7:
Поднимаясь на уровень выше, начинаем говорить про уровень программный. Вобщем-то, в юникс-подобных системах весьма неплохо сделана система разграничения прав, и если права выставлены грамотно, и нет возможности их нарушить (система достаточно надёжна) --- то всё хорошо. Первое, о чем необходимо помнить: борьба за безопасность начинается с физического уровня. Если у злоумышленника есть возможность развинтить компьютер, чтобы получить информацию, то он это сделает. Таким образом, единственный защиты информации при возможности физического доступа к ней --- шифрование диска на уровне его контроллера. Поэтому защита данных на уровне их секретности начинается с административных мер, а не с программных. В первую очередь, никто не должен иметь физический доступ к серверу и физический доступ к его консоли: это позволит злоумышленнику легко войти в cистему, даже не зная пароль администратора, например, используя параметр ядра {{{init=/bin/bash}}}.
Line 9: Line 9:
Кстати очень многие службы не стартуют, если секретные данные доступны не только службе и руту. К счастью, есть такая штука, как umask, которая указывает, какие права будут убиваться при создании файла (к примеру, umask 022 означает снятие бита записи в группах доступа g и o, то есть права вида 755). Поднимаясь на уровень выше, рассмотрим уровень программный. В целом, в Unix-подобных системах успешно функционирует система разграничения прав: если права выставлены грамотно, то нет возможности их нарушить, и система достаточно надёжна. Более того, очень многие службы не стартуют, если секретные данные доступны не только пользователю данной службы и администратору.
Line 11: Line 11:
Нелишне помнить, что говоря о надёжности системы, мы говорим в том числе об атаках на отказ в обслуживании. То есть, сказали что-то сервису, и он взял и упал, когда мы говорим о том, что необходимо обеспечивать разграничение прав в системе, мы забываем, что есть ещё такие ресурсы, как оперативная память и процессорное время. И то, и другое при удачном стечении обстоятельств может быть съедено в достаточной степени для того, чтобы система перестала работать в штатном режима. В линуксе нельзя одним процессом, если он не рутвый, всё время съесть (ограничения приоритета --- его нельзя повысить, если ты не рут, только понизить). Но есть ещё ресурс количества процессов, принадлежащих одному пользователю: если вы хотите пожрать процессорное время, то ваша задача запустить как можно больше процессов. Для облегчения манипуляций с правами в ПСПО существует утилита {{{umask}}}, изменяющая права доступа, которые присваиваются новым файлам и директориям по умолчанию, иными словами, снимающая те или иные права. Например, {{{umask 022}}} означает снятие бита записи в группах доступа g и o, то есть права вида 755.
Line 13: Line 13:
## Сейчас лектор покажет, как это регулируется: ulimit. man limits.conf. Есть штука, которая пзв. эту ситуацию предотвратить. view /etc/security/limits.conf . Это можно привязать как к польз., так и к группе. братите внимание, чт лимиты эти явл. частью окр., из шела оно добывается в ulimit, при логине эти лимиты вменяются, и их нельзя никак улучшить. Когда вы логиничтесь в системе, запускается логин шелл, ему в окр. пропихиваются эти лимиты, и их вы не мжете никак поменять. Разумеется, при ред. этого файла ничего не меняется для запущеннных процессв. Это не свойсто системы, а свойство процесса, обл. функцией ридонли. Поскольку ПСПО состоит из различных программ, которые имеют разные уровни доступа к разным объектам системы, необходимо сделать так, чтобы процессы какого-нибудь случайного пользователя системы не навредили нашим объектам. Итак, одним пользователями мы разрешаем запускать те или иные процессы, а другим --- нет.
Line 15: Line 15:
Всяческие ограничения, накладываемые на пользовательские процессы, задаются при помощи системы ulimit (полную информацию о том, насколько вас ограничили, можно узнать, сказав шеллу ulimit -a). Параметры записаны в файле /etc/security/ulimits.conf. Ограничивать можно и отдельных пользователей, и группы. Все эти настройки записываются в окружение login shell пользователю таким образом, что не могут быть далее изменены, и, соответственно, наследуются всеми процессами пользователя. === Атаки отказа в обслуживании ===
Line 17: Line 17:
## Как броться с форковой бомбой --- прблема в том, пока их убиваешь, они нарождаются. Не исключено, что время вып. скрипта, кторый мы напишем, не убъёт всё. Лучше всего зайти другим польз, хтя можно и этим. Проблема в чём? Аккуратно написанная форквая омба работает быстрее, чем команда kill, и как тольк вы не добьёте хотя бы одну ветку, она экспоненциальн разрастётся. Поэтому эти прцессы надо удивать не сигналом KILL, а сигналом STOP. Тгда они не удаляются из таблицы прцессов и не работают. В данном слчуае очень просто --- killall -STOP ach, после чего killall -KILL ash. Стоит отметить, что, говоря о надёжности системы, мы говорим в том числе и об атаках на отказ в обслуживании (DoS-атаки, от англ. ''Denial of Service''). Хотя под такими атаками сейчас часто подразумевают сетевые атаки (которые более точно называются DDoS-атаками, от англ. ''Distributed Denial of Service'')), отказ в обслуживании может быть вызван и действиями одного локального пользователя. Поэтому необходимо сделать так, чтобы в результате некоторых действий локального пользователя система не перестала бы быть способной выполнять полезную работу.
Line 19: Line 19:
Весьма популярным способом DOS-атаки системы с плохо настроенным ограничением на число процессов одного пользователя --- так называемая fork-бомба, то есть программа, которая не делает ничего, кроме как с максимальной скоростью порождает собственные копии в больших количествах, в идеальном случае занимая всю память и большую часть процессорного времени. Просто посылать сигналы на завершение работы этой стае напильников совершенно бесполезно, поскольку --- даже если были достигнуты ограничения на число процессов --- как только кто-то умрёт, на их места тут же встанут новые процессы. В принципе, можно попытаться написать собственную форк-бомбу, задача которой --- убивать предыдущую, но скорее всего это только усугубит проблему. Вариант выхода из такой ситуации --- послать всем бомбовым процессам не SIGKILL, а SIGSTOP. Тогда они прекратят своё выполнение, но не будут удалены из таблицы процессов --- они будут всего лишь приостановлены, и их после остановки можно будет легко и просто убить. При возможности управлять ситуацией от лица суперпользователя будет полезно воспользоваться утилитой killall в виде killall -u <имя хулиганящего пользователя> -STOP, и потом killall -u <имя хулиганящего пользователя> -KILL. Когда мы говорим о том, что необходимо обеспечивать разграничение прав в системе, нельзя забывать о том, что существуют такие ресурсы, как оперативная память и процессорное время. И то, и другое при определенном стечении обстоятельств может быть загружено в достаточной степени для того, чтобы система перестала работать в нормальном режиме. В Unix-системах нельзя одним процессом, если он не запущен от пользователя root, занять всё процессорное время. Это происходит из-за ограничений приоритета процесса --- его нельзя повысить, если Вы не вошли в систему как root, можно только понизить. Но есть ещё ресурс количества процессов, принадлежащих одному пользователю: если вы хотите занять процессорное время, очевидно, ваша задача --- запустить как можно больше процессов.
Line 21: Line 21:
## Мы позанимались каким-то странным асп. безопасности. Теперь про запретный плод: в этм случае всё, что не запрещ., разрешено хорошоа. Если вы не боитесь ост. в процессе, и готовы быстро восст. при возн. неполадок. И лучше, чтбы дырки и люди были известные, ибо эти люди мтивированы компьютером, и лучше их тлавливать на этом этапе и перевоспитывать. Весьма популярным способом DoS-атаки системы с плохо настроенным ограничением на число процессов одного пользователя --- так называемая fork-бомба, то есть программа, которая не делает ничего, кроме как с максимальной скоростью создает собственные копии в больших количествах, в идеальном случае занимая всю память и большую часть процессорного времени. Для этого потенциальному злоумышленнику достаточно выполнить, например, следующую команду.
{{{
$ bomb() { bomb | bomb& }; bomb
}}}
Line 23: Line 26:
Определённым недостатком всей той системы безопасности, что есть у нас, является тот факт, что всё, что не запрещено --- разрешено, что, как ни крути, даёт некий простор для творчества людей, которые могут и хотят творить в этой области. На факультете ВМК МГУ такие в итоге становятся системными администраторами. Она создает шелл-функцию с именем bomb, которая начинает рекурсивно запускать саму себя дважды, при этом создается два новых процесса, которые в свою очередь порождают четыре процесса, и так далее. Очевидно, что без ограничений на количество процессов, запущенных одним пользователем, такая команда быстро вызовет отказ обслуживания. Просто посылать сигналы на завершение работы этих программ совершенно бесполезно, поскольку, даже если было достигнуто предельное число процессов, как только один из них завершит работу, на его место тут же встанет новый процесс. В принципе, можно попытаться даже написать собственную fork-бомбу, задача которой --- убивать предыдущую, но, скорее всего, это только усугубит проблему. Вариант выхода из такой ситуации --- послать всем бомбовым процессам не {{{SIGKILL}}}, а {{{SIGSTOP}}}. Тогда они прекратят своё выполнение, но не будут удалены из таблицы процессов; они будут всего лишь приостановлены, и после остановки их можно будет легко завершить. При возможности управлять ситуацией от лица суперпользователя будет полезно воспользоваться утилитой killall, выполнив команды:
{{{
# killall -u <имя запускающего такие процессы пользователя> -STOP
# killall -u <имя запускающего такие процессы пользователя> -KILL
}}}
Однако ясно, что правильным методом борьбы с бомбами является ограничение числа процессов пользователя, что и сделано в современных системам GNU/Linux.
Line 25: Line 33:
## Ещё одно это пароли. Если отоносится к личным учётным записям как к возм. доступа к личной информации, то ... . Известное дело, что утечка идент. инф. приводит к тому, что плучен доступ ко всей инф., которая защищена ею. Стоит иметь в виду, чт прежде чем говорить о такго рода защите, нужно убедиться в том, чт все файлы и так не откр. на чтение раз., никакой возм. (в концепции класса можно иметь свю машину с лок. рутом, потом любым польз. и получить доступ к его данным. Это из того, что у nfs ip-based авторизация, и мы считаем все лок. машины своими) получить доступ в обхд правил. Ещё одна вещь --- хранение файлов на ФС без возм. хранения прав. Возвращаясь к ситуации, когда это соблюдено и нужно уберечь учётные записи от утечки. Снчала следует сказать, что в позиксе давно никаких паролей (авторизационного слова) не хранится. Вместо парля в линуксе хранится хэш. Зайдём в рута и покажем хэш от польз. root. Хэш эт один из видов шифрвания с потерей. Смысл хэша состоит в ом, чтобы сгенерировать дост. большой объём данных, чтбы вероятность свп. двух хэшей была чень низкой, с рйгой стороны, возм. восст. исх .текста по хэщу отсутствовала. И чтобы этот хэш мжн было вычислить из исх. данных. Именно так и происх. прцесс авторизации. === Ограничение ресурсов, выделяемых процессам пользователя ===
Line 27: Line 35:
Теперь --- о паролях и о аутентификации. Очевидно, что утечка идентификационной информации равнозначна утечке той информации, которая доступна при аутентификации с помощью этого идентификатора. Но иногда есть и другие способы получить доступ к тем или иным образом защищённой информации. К примеру, в концепции класса активно используется сетевая файловая система NFS, авторизация в которой осуществляется по IP-адресам. То есть любой человек, имеющий пользователя root на локальной машине, теоретически может напакостить на сервере. Или же, файлы с сильно ограничивающими к ним доступ правами случайно копируются на файловую систему, которая не поддерживает права доступа --- так же не очень приятная ситуация. Различные ограничения, накладываемые на пользовательские процессы, задаются при помощи системы {{{ulimit}}}. Полную информацию о том, насколько Вас ограничили, можно узнать, выполнив команду {{{ulimit -a}}}.
{{{
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
max nice (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 1983
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
max rt priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 256
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
}}}
Эти параметры записаны в файле `/etc/security/limits.conf`. Ограничивать можно и отдельных пользователей, и группы. Все эти настройки записываются в окружение оболочки входа в систему (''login shell'') пользователя таким образом, что не могут быть изменены, и, соответственно, наследуются всеми процессами пользователя.
Line 29: Line 57:
О хорошем. С довольно давних пор в POSIX-системах нигде на диске не хрянатся пароли в явном виде --- только невосстановимые хэши от оных. Хэш отличается двумя важными свойствами --- у одинаковых данных он одинаков, и очень трудно подобрать разные данные. у которых он будет одинаков. Тем самым легко сверять пароль по совпадению хэша от пароля. Определённым недостатком всей имеющейся у нас системы безопасности является тот факт, что всё, что не запрещено --- разрешено, что даёт некий простор для творчества людей, которые могут и хотят творить в этой области.
Line 31: Line 59:
## Обр. внимание, чт в отл. от ст. учебников линукс, где написан, что все хэши лежат в /etc/shadow, тут более сложная система, которая взята из архитектуры TCB, в частности, архитектура работы с паролями (tcb). С точик зр. рядового польз. эт выглядит, что у каждог польз. есть свой собст. shadow. Итак, хэш это функц., обл. этими тремя свойствами. Таких функций много. В альте исп. blowfish, в других линуксах md5, в старых юниксах des. Для того, чтобы нельзяб ыло сост. такой техн. индекс (у нас есть пароль, есть хэш), в другом месте другой человек придумал тот же пароль, и у него тогда будет тот же хэш. Чтобы такого не происходило, в исх. включается некий sold(?): $2a --- sold, $08 --- количество применений алгоритма самому к себе. 8-кратное применение работает доли секунды. То есть обычному пльз. не заметно, а перебор затрудняет. Сделано это, чтобы повысить выч. сложность хэша и затруднить перебор. Т. о., когда вы второй раз ввдите пароль, прграммал лезет в shadow, вынимает sold, кол-во вызовов, применяет к паролю с sold'ом функцию необх. кол-во раз и сравнивает хэш. === Пароли и их криптографическая стойкость ===
Line 33: Line 61:
В отличие от традиционного для большинства систем файла `/etc/shadow`, в котором хранятся хэши паролей всех пользователей, в ПСПО используется система, взятая из TCB (Trusted Computing Base ?), когда для каждого пользователя имеется свой файл shadow, находящийся в соответствующем подкаталоге `/etc/tcb`. Это позволяет, к примеру, не держать утилиту passwd как suid root. Речь здесь пойдет о паролях и об аутентификации. Очевидно, что утечка идентификационной информации равнозначна утечке той информации, которая доступна при аутентификации с помощью этого идентификатора. Но иногда есть и другие способы получить доступ к тем или иным образом защищённой информации. Например, в концепции класса активно используется сетевая файловая система NFS, авторизация в которой обычно осуществляется по IP-адресам. Иными словами, любой человек, имеющий пользователя root на локальной машине, теоретически может производить опеределенные (в том числе вредоносные) операции на сервере. Или же, файлы с сильно ограничивающими к ним доступ правами случайно копируются на файловую систему, которая не поддерживает права доступа --- также не очень приятная ситуация.
Line 35: Line 63:
Для затруднения подбора пароля так называемым "индексированием" хэша --- когда злоумышленник проверяет хэши у различных паролей, и при совпадении хэша он узнаёт правильный пароль --- есть несколько взаимодополняющих путей. Первый --- это усложнение алгоритма вычисления хэша, как-то, применение функции несколько раз. Для однократной проверки при входе в систему время пренебрежимо мало, при переборе большого числа значений --- очень велико. Второй, гораздо более важный --- при первоначальном подсчёте хэша он считается не только от пароля, но и он некоей дополнительной информации, получаемой случайно и именуемой salt (соль). В итоге в shadow каждого пользователя сохраняется собственно хэш, соль, и количество применений хэш-функции к паролю (обыкновенно чуть менее десяти). С довольно давних пор в POSIX-системах нигде на диске не хранятся пароли в явном виде --- только невосстановимые хэши от них, получаемые применением к паролям хэш-функции, которая преобразовывает их в битовую строку фиксированной длины, из которой пароль восстановить нельзя. Хэш отличается двумя важными свойствами --- у одинаковых данных он одинаков, и очень трудно подобрать разные данные, для которых он будет одинаков (и если такой алгоритм обнаруживается, то переходят на более стойкую функцию вычисления хешей). Таким образом, легко сверять пароль по совпадению хэша от пароля.
Line 37: Line 65:
## Лектор возвр. к идеи крипт. пароля, которая, спасиб OWL, в посл. версии заьбита, причём в посл. версии pam-qc, качество пароля настраиваемо. Идея в чём --- чтобы пароль был криптостойкий, нужно всего лишь ... Есть файл /etc/passwdqc.conf, к нему должны ходить программы, проверяющие кач-во паролей. Это часть пам, и все, кто им пользуются, будут его исп. Макс. длина пароля опр. для разл. старых сист. служб. Чуть выше видим параметры минимальной длины пароля для парлей разных видов. Почему такие хитрости, почему не сказать, что пароль должен быть длиннее 16 символов. Это неправда, пск пароль из 16 нулей некриптостоек, если мы подглядели, что польз. давит на одну клавишу. Эти категории паролей отн. к классам символов. Гворя простым языком: если у вас встречаются тольк буквы и цифры или проблеы, т пароль должен быть длинным, поск. букв мало, буквы складываются в лова, а их ещё меньше. Поэтому, если ольз. хчет, чтобы парль сост. из влов, то нужна одна длина пароля. Если польз. согл. исп. маленькие и большие буквы и ни не слова, то парль может быть покороче. Если он готов исп. символы 4 категорий, т пароль может быть ещё меньше. Вт эта надпись,Ю кторую мы видим в конфиге, озн., что 24 символа --- пассфраза из букв двух категорий (два чарактер класса), если готовы запоминать странные символы между ними --- 12, если три категории --- 8, четыре --- 7. Изм. этих настр. ведёт к изм. допустимого ур. безопасности. В отличие от традиционного для большинства систем файла `/etc/shadow`, в котором хранятся хэши паролей всех пользователей, в ПСПО используется система, взятая из TCB (Trusted Computing Base), когда для каждого пользователя имеется свой файл shadow, находящийся в соответствующем подкаталоге `/etc/tcb`. Это позволяет,например, не держать утилиту passwd как suid root.
Line 39: Line 67:
Криптографическая стойкость, она же надёжность, пароля. В ALT Linux и OWL проверяется при помощи pam_passwd_qc (Password Quality Control), подсистемы PAM, которая позволяет задать некоторые ограничения, которым должен соответствовать пароль, как-то: минимальная длина при использовании одного, двух, трёх, четырёх классов символов, максимальная длина, состоит ли пароль из словарных слов или нет. Очевидно, что чем больше различных классов символов в пароле, тем он может быть короче --- но тем труднее его будет запомнить. Понятно, что по умолчанию отключено создание паролей из символов одного класса --- как бы длинны они не были. Ведь это означает теоретическую возможность создать пароль из, к примеру, большого числа одинаковых символов, который при всём желании трудно назвать стойким ко взлому. Для затруднения подбора пароля так называемым "индексированием" хэша --- когда злоумышленник проверяет хэши у различных паролей, и при совпадении хэша он узнаёт правильный пароль --- есть несколько взаимодополняющих путей. Первый --- это усложнение алгоритма вычисления хэша, например, применение функции несколько раз для замеделния процесса вычисления хеша. При однократной проверки при входе в систему это время все равно будет пренебрежимо мало, но при переборе большого числа значений оно становится очень ощутимо. Второй, гораздо более важный --- при первоначальном подсчёте хэша он считается не только от пароля, но и он некоей дополнительной информации, получаемой случайно и именуемой ''salt'' (соль). В итоге в shadow каждого пользователя сохраняется собственно хэш, соль и количество применений хэш-функции к паролю (обычно менее десяти).
Line 41: Line 69:
В числе прочего не рекомендуется использовать имя пользователя как часть пароля, пароль в одно слово и так далее. Всё это не даст сделать qc, но он не везде включён и для рута он просто выключен.
Вернее, не то чтобы совсем выключен --- суперпользователь будет предупреждён о нестойкости пароля, но изменён он, тем не менее, будет. Стоит заметить что это поведение pam_passwd_qc по умолчанию, которое можно изменить в соответствующем объекте подсистемы control.
Криптографическая стойкость (она же надёжность) пароля в ALT Linux и OWL проверяется при помощи passwdqc-enforce (Password Quality Control), подсистемы, которая позволяет задать некоторые ограничения, которым должен соответствовать пароль, например: минимальная длина при использовании одного, двух, трёх, четырёх классов символов, максимальная длина, состоит ли пароль из словарных слов или нет. Очевидно, что чем больше различных классов символов в пароле, тем он может быть короче --- но тем труднее его будет запомнить. Понятно, что по умолчанию отключено создание паролей из символов одного класса, как бы длинны они не были. Ведь это означает теоретическую возможность создать пароль из, к примеру, большого числа одинаковых символов, который нельзя назвать стойким ко взлому.
Line 44: Line 71:
## Мы видим на экр. усп. обновление пароля. В числе прочего не рекомендуется использовать имя пользователя как часть пароля, пароль в одно слово и так далее. Всё это не даст сделать система контроля качества паролей, но он не везде включён, например выключен при выполнении от пользователя root. Суперпользователь будет лишь предупреждён о нестойкости пароля, но изменён он, тем не менее, будет. Стоит заметить, что это настройки passwdqc-enforce по умолчанию, которые можно изменить в соответствующем объекте подсистемы control.
Line 46: Line 73:
Какие бывают алгоритмы составления более-менее стойких паролей: строчка из песни, первые буквы чего-нибудь, русские слова по английской раскладке, желательно, чтобы там были не только буквы, но и знаки препинания (русские буквы Э, Ж и тому подобное). Пока это работает, хотя леткор предвидит, что вскоре будет искаться и по этому способу. Подбор пароля в противном случае (по словарю) может занять доли секунды. Лектору на данный момент точно неизвестны подборщики паролей, которые ходят по паролям в стиле leet русским (H@TTpumep, BoT T@K). Крме того, там не только посимвольная замена, в отличие от классического leetspeak (к примеру, }|{, 9|). Рассмотрим пример успешного обновления пароля. Так, passwdqc-enforce предлагает пароль, который, по её мнению, достаточно криптостоек --- произвольные словарные слова, разделённые произвольными знаками препинания:
{{{
[user@demo ~]$ passwd
Changing password for user.
Enter current password:
Line 48: Line 79:
Пароли не надо записывать, их надо запоминать. Существуют программы хранения паролей, которые их защищают другим паролем. You can now choose the new password or passphrase.
Line 50: Line 81:
Лектор забыл упомянуть ещё одну важную вещь, поск. не было разговора пр иксы. Есть отдельный класс подсм. логин под нзванием кейлоггер. Это программа, которая пишет всё, что печатается на клавиатуре. В линуксе есть два места: системная кнсоль, другая штука --- иксы. Когда вы вводите логин-пароль, вы взаимод. xdm, она запускается от рута, и елси кто-то подменил xdm, т он имеет рута, а тут уже какая разница. Даже без локлаьного рута можно легко отдать свои логин-пароль кому-то ни было, если предп. некие действия. Х-сервер работает как неке приложение, которое принимает события с мыши-клавиатуры, и передаёт дальше. Есть wm, который их принимает и раздаёт дальше. Можно написать программу, которая перехватывет их раньше и складывать их куда-то. Эта программа отлжит все нажатия, в том числе логин и пароль. То, что вы можете написать такую программу ... главное, то, что вы можете их запустить. Взхм. запуска пр. методом авторихвации. Первый --- ip-based авторизация. Лектор не советует её включать, пск. может оказаться, что на машине окажется лругой человек. Другой вариант --- исп. MIT magic cookie, xauth, при запуске х-клиент должен дать х-серверу куку, которая лежит в файле, и тут возн. уровень безопаснсти, и при удалённом запуске надо проделать некие телодвижения, чтобы кука оказалась на другой стороне. Есть проблема --- сам по себе X-траффик не шифруется. A valid password should be a mix of upper and lower case letters,
digits, and other characters. You can use an 8 character long
password with characters from at least 3 of these 4 classes, or
a 7 character long password containing characters from all the
classes. An upper case letter that begins the password and a
digit that ends it do not count towards the number of character
classes used.
Line 52: Line 89:
Смысл состоит в слеждующем: даже если вы уверены, что если вам за спину никто не глядит, то если вы работаете через сеть с иксами не по ссх, то есть вероятность, что что-то утечёт. A passphrase should be of at least 3 words, 12 to 40 characters
long and contain enough different characters.
Line 54: Line 92:
Alternatively, if noone else can see your terminal now, you can
pick this as your password: "count!diesel!noise".

Enter new password:
Re-type new password:
passwd:
all authentication tokens updated successfully.
}}}

Часто используемые алгоритмы составления достаточно стойких паролей: строчка из песни, первые буквы чего-нибудь, русские слова в английской раскладке, желательно, чтобы там были не только буквы, но и знаки препинания (русские буквы Э, Ж и тому подобное). Пока это работает, хотя, судя по всему, вскоре программы перебора паролей будут искать и по этим алгоритмам. Подбор пароля по словарю может занять доли секунды. Лектору на данный момент точно неизвестны подборщики паролей, которые перебирают по паролям в стиле leet русским (H@TTpumep, BoT T@K). Кроме того, там может присутствовать не только посимвольная замена, в отличие от классического leetspeak (к примеру, }|{, 9|).

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

=== Различные способы узнать ваш пароль ===

Также не стоит забывать о том, что какой бы пароль криптостойкий не был, всегда существует способ не подобрать его, но тем или иным способом узнать непосредственно. Существует такой класс программ как "клавиатурные воры", или кейлоггеры, которые записывают каждое нажатие на клавиатуру. В системе GNU/Linux у неё есть два основных пути: системная консоль (что потребует прав root и модификации ядра, а при таком уровне доступа можно и более простым путём украсть данные) и X-сервер, а также перехват на уровне ядра операционной системы. Архитектура X-сервера такова, что может существовать программа, которая перехватывает все события с клавиатуры и перенаправляет их конкретным приложениям. Так работают, например, все оконные менеджеры. Поэтому, работая на недоверенной машине, нельзя быть уверенным, что такая программа не включена.

Эмулятор терминала xterm имеет в себе оригинальный способ решения проблемы кейлоггера: существует режим работы Secure Keyboard, когда сам xterm становится программой, которая захватывает клавиатуру. При включении этого режима xterm инвертирует цвет терминала, и в случае запуска другой захватывающей клавиатуру программы --- а такая может быть только одна --- цвета изменятся обратно, что будет служить знаком того, что ценные данные вводить не стоит. Тем не менее, это не слишком надежный способ контроля перехвата клавиатуры, поскольку в случае недоверенной машины он может быть также произведен на уровне ядра операционной системы.

Следует отметить, что Х-сервер и приложение могут находится на разных компьютерах, а для подключения к запущенному X-серверу приложения должны проходить авторизацию. Авторизация бывает двух видов: по хостам (довольно ненадёжно, вдруг какой-нибудь другой пользователь запустит кейлоггер), и по MIT Magic Cookie (специальному хэшу). Первый регулируется утилитой xhost, второй --- xauth. Второй, в принципе, достаточно надёжен, если не принимать во внимание то, что сам по себе сетевой трафик по протоколу X не шифруется. Поэтому, даже если вы уверены, что если вам за спину никто не смотрит, работать через сеть с Х-приложениями следует только по SSH (о котором речь пойдет далее), иначе некоторая часть информации может быть просмотрена нежелательными людьми.
Line 61: Line 119:
|| 11 || 1 || 1 || 1 || || 1 || MaximByshevskiKonopko, ОльгаТочилкина, VsevolodKrishchenko || || || || 90 || 1 || 1 || 1 || || 1 || MaximByshevskiKonopko, ОльгаТочилкина, VsevolodKrishchenko || || ||

Локальная безопасность

Рассмотрим сначала вопросы обеспечения безопасности локальной работы компьютера, не касаясь вопросов безопасной передачи данных по сети или сетевых атак.

Доступность: физическая и виртуальная

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

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

Для облегчения манипуляций с правами в ПСПО существует утилита umask, изменяющая права доступа, которые присваиваются новым файлам и директориям по умолчанию, иными словами, снимающая те или иные права. Например, umask 022 означает снятие бита записи в группах доступа g и o, то есть права вида 755.

Поскольку ПСПО состоит из различных программ, которые имеют разные уровни доступа к разным объектам системы, необходимо сделать так, чтобы процессы какого-нибудь случайного пользователя системы не навредили нашим объектам. Итак, одним пользователями мы разрешаем запускать те или иные процессы, а другим --- нет.

Атаки отказа в обслуживании

Стоит отметить, что, говоря о надёжности системы, мы говорим в том числе и об атаках на отказ в обслуживании (DoS-атаки, от англ. Denial of Service). Хотя под такими атаками сейчас часто подразумевают сетевые атаки (которые более точно называются DDoS-атаками, от англ. Distributed Denial of Service)), отказ в обслуживании может быть вызван и действиями одного локального пользователя. Поэтому необходимо сделать так, чтобы в результате некоторых действий локального пользователя система не перестала бы быть способной выполнять полезную работу.

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

Весьма популярным способом DoS-атаки системы с плохо настроенным ограничением на число процессов одного пользователя --- так называемая fork-бомба, то есть программа, которая не делает ничего, кроме как с максимальной скоростью создает собственные копии в больших количествах, в идеальном случае занимая всю память и большую часть процессорного времени. Для этого потенциальному злоумышленнику достаточно выполнить, например, следующую команду.

$ bomb() { bomb | bomb& }; bomb

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

# killall -u <имя запускающего такие процессы пользователя> -STOP
# killall -u <имя запускающего такие процессы пользователя> -KILL

Однако ясно, что правильным методом борьбы с бомбами является ограничение числа процессов пользователя, что и сделано в современных системам GNU/Linux.

Ограничение ресурсов, выделяемых процессам пользователя

Различные ограничения, накладываемые на пользовательские процессы, задаются при помощи системы ulimit. Полную информацию о том, насколько Вас ограничили, можно узнать, выполнив команду ulimit -a.

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
max nice                        (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 1983
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
max rt priority                 (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 256
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

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

Определённым недостатком всей имеющейся у нас системы безопасности является тот факт, что всё, что не запрещено --- разрешено, что даёт некий простор для творчества людей, которые могут и хотят творить в этой области.

Пароли и их криптографическая стойкость

Речь здесь пойдет о паролях и об аутентификации. Очевидно, что утечка идентификационной информации равнозначна утечке той информации, которая доступна при аутентификации с помощью этого идентификатора. Но иногда есть и другие способы получить доступ к тем или иным образом защищённой информации. Например, в концепции класса активно используется сетевая файловая система NFS, авторизация в которой обычно осуществляется по IP-адресам. Иными словами, любой человек, имеющий пользователя root на локальной машине, теоретически может производить опеределенные (в том числе вредоносные) операции на сервере. Или же, файлы с сильно ограничивающими к ним доступ правами случайно копируются на файловую систему, которая не поддерживает права доступа --- также не очень приятная ситуация.

С довольно давних пор в POSIX-системах нигде на диске не хранятся пароли в явном виде --- только невосстановимые хэши от них, получаемые применением к паролям хэш-функции, которая преобразовывает их в битовую строку фиксированной длины, из которой пароль восстановить нельзя. Хэш отличается двумя важными свойствами --- у одинаковых данных он одинаков, и очень трудно подобрать разные данные, для которых он будет одинаков (и если такой алгоритм обнаруживается, то переходят на более стойкую функцию вычисления хешей). Таким образом, легко сверять пароль по совпадению хэша от пароля.

В отличие от традиционного для большинства систем файла /etc/shadow, в котором хранятся хэши паролей всех пользователей, в ПСПО используется система, взятая из TCB (Trusted Computing Base), когда для каждого пользователя имеется свой файл shadow, находящийся в соответствующем подкаталоге /etc/tcb. Это позволяет,например, не держать утилиту passwd как suid root.

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

Криптографическая стойкость (она же надёжность) пароля в ALT Linux и OWL проверяется при помощи passwdqc-enforce (Password Quality Control), подсистемы, которая позволяет задать некоторые ограничения, которым должен соответствовать пароль, например: минимальная длина при использовании одного, двух, трёх, четырёх классов символов, максимальная длина, состоит ли пароль из словарных слов или нет. Очевидно, что чем больше различных классов символов в пароле, тем он может быть короче --- но тем труднее его будет запомнить. Понятно, что по умолчанию отключено создание паролей из символов одного класса, как бы длинны они не были. Ведь это означает теоретическую возможность создать пароль из, к примеру, большого числа одинаковых символов, который нельзя назвать стойким ко взлому.

В числе прочего не рекомендуется использовать имя пользователя как часть пароля, пароль в одно слово и так далее. Всё это не даст сделать система контроля качества паролей, но он не везде включён, например выключен при выполнении от пользователя root. Суперпользователь будет лишь предупреждён о нестойкости пароля, но изменён он, тем не менее, будет. Стоит заметить, что это настройки passwdqc-enforce по умолчанию, которые можно изменить в соответствующем объекте подсистемы control.

Рассмотрим пример успешного обновления пароля. Так, passwdqc-enforce предлагает пароль, который, по её мнению, достаточно криптостоек --- произвольные словарные слова, разделённые произвольными знаками препинания:

[user@demo ~]$ passwd
Changing password for user.
Enter current password: 

You can now choose the new password or passphrase.

A valid password should be a mix of upper and lower case letters,
digits, and other characters.  You can use an 8 character long
password with characters from at least 3 of these 4 classes, or
a 7 character long password containing characters from all the
classes.  An upper case letter that begins the password and a
digit that ends it do not count towards the number of character
classes used.

A passphrase should be of at least 3 words, 12 to 40 characters
long and contain enough different characters.

Alternatively, if noone else can see your terminal now, you can
pick this as your password: "count!diesel!noise".

Enter new password: 
Re-type new password: 
passwd: 
all authentication tokens updated successfully.

Часто используемые алгоритмы составления достаточно стойких паролей: строчка из песни, первые буквы чего-нибудь, русские слова в английской раскладке, желательно, чтобы там были не только буквы, но и знаки препинания (русские буквы Э, Ж и тому подобное). Пока это работает, хотя, судя по всему, вскоре программы перебора паролей будут искать и по этим алгоритмам. Подбор пароля по словарю может занять доли секунды. Лектору на данный момент точно неизвестны подборщики паролей, которые перебирают по паролям в стиле leet русским (H@TTpumep, BoT T@K). Кроме того, там может присутствовать не только посимвольная замена, в отличие от классического leetspeak (к примеру, }|{, 9|).

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

Различные способы узнать ваш пароль

Также не стоит забывать о том, что какой бы пароль криптостойкий не был, всегда существует способ не подобрать его, но тем или иным способом узнать непосредственно. Существует такой класс программ как "клавиатурные воры", или кейлоггеры, которые записывают каждое нажатие на клавиатуру. В системе GNU/Linux у неё есть два основных пути: системная консоль (что потребует прав root и модификации ядра, а при таком уровне доступа можно и более простым путём украсть данные) и X-сервер, а также перехват на уровне ядра операционной системы. Архитектура X-сервера такова, что может существовать программа, которая перехватывает все события с клавиатуры и перенаправляет их конкретным приложениям. Так работают, например, все оконные менеджеры. Поэтому, работая на недоверенной машине, нельзя быть уверенным, что такая программа не включена.

Эмулятор терминала xterm имеет в себе оригинальный способ решения проблемы кейлоггера: существует режим работы Secure Keyboard, когда сам xterm становится программой, которая захватывает клавиатуру. При включении этого режима xterm инвертирует цвет терминала, и в случае запуска другой захватывающей клавиатуру программы --- а такая может быть только одна --- цвета изменятся обратно, что будет служить знаком того, что ценные данные вводить не стоит. Тем не менее, это не слишком надежный способ контроля перехвата клавиатуры, поскольку в случае недоверенной машины он может быть также произведен на уровне ядра операционной системы.

Следует отметить, что Х-сервер и приложение могут находится на разных компьютерах, а для подключения к запущенному X-серверу приложения должны проходить авторизацию. Авторизация бывает двух видов: по хостам (довольно ненадёжно, вдруг какой-нибудь другой пользователь запустит кейлоггер), и по MIT Magic Cookie (специальному хэшу). Первый регулируется утилитой xhost, второй --- xauth. Второй, в принципе, достаточно надёжен, если не принимать во внимание то, что сам по себе сетевой трафик по протоколу X не шифруется. Поэтому, даже если вы уверены, что если вам за спину никто не смотрит, работать через сеть с Х-приложениями следует только по SSH (о котором речь пойдет далее), иначе некоторая часть информации может быть просмотрена нежелательными людьми.


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

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

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

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

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

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

Level

Maintainer

Start date

End date

90

1

1

1

1

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


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

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