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

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

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

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

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

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

DoS-атаки, ограничения

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

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

[user@demo ~]$ 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/ulimits.conf. Ограничивать можно и отдельных пользователей, и группы. Все эти настройки записываются в окружение login shell пользователя таким образом, что не могут быть изменены, и, соответственно, наследуются всеми процессами пользователя.

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

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

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

Речь пойдет о паролях и о аутентификации. Очевидно, что утечка идентификационной информации равнозначна утечке той информации, которая доступна при аутентификации с помощью этого идентификатора. Но иногда есть и другие способы получить доступ к тем или иным образом защищённой информации. Например, в концепции класса активно используется сетевая файловая система 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), подсистемы, которая позволяет задать некоторые ограничения, которым должен соответствовать пароль, как-то: минимальная длина при использовании одного, двух, трёх, четырёх классов символов, максимальная длина, состоит ли пароль из словарных слов или нет. Очевидно, что чем больше различных классов символов в пароле, тем он может быть короче --- но тем труднее его будет запомнить. Понятно, что по умолчанию отключено создание паролей из символов одного класса --- как бы длинны они не были. Ведь это означает теоретическую возможность создать пароль из, к примеру, большого числа одинаковых символов, который при всём желании трудно назвать стойким ко взлому.

В числе прочего не рекомендуется использовать имя пользователя как часть пароля, пароль в одно слово и так далее. Всё это не даст сделать qc, но он не везде включён и для рута он просто выключен. Вернее, не то чтобы совсем выключен --- суперпользователь будет предупреждён о нестойкости пароля, но изменён он, тем не менее, будет. Стоит заметить что это поведение 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|).

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

И тем не менее...

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

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

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


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

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

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

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

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

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

Level

Maintainer

Start date

End date

39

1

1

1

1

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


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex