Настройка безопасности пользователей


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

Ограничение возможности входа

Всякий раз, когда пользователь пытается войти в систему, FreeBSD проверяет содержимое файла /etc/login.access. Если там есть правила, запрещающие вход в систему того или иного пользователя, то его попытка зарегистрироваться немедленно провалится. По умолчанию этот файл пуст — нет никаких ограничений для пользователей, имеющих имя и пароль.

В файле /etc/login.access есть три поля, разделенных двоеточиями. Первое поле предоставляет (+) или отнимает (-) право на вход в систему; второе поле — список пользователей или групп; третье — список источников подключений. Можно также использовать выражения ALL (все) и ALL EXCEPT (все, за исключением), позволяя администратору задавать простые, но выразительные правила. Программа входа в систему проверяет правила, руководствуясь первым совпадением, а не лучшим. Когда программа login(1) находит правило, которому соответствуют и группа, и источник подключения, соединение немедленно разрешается или отклоняется. Значит, порядок правил очень важен. Например, чтобы разрешить регистрацию с системной консоли только членам группы wheel, можно попробовать следующее:

+:wheel: console

Однако с этим правилом не все в порядке: на самом деле оно не отменяет полномочий пользователей на вход в систему. По умолчанию регистрация разрешена, а все, что делает это правило, — явно предоставляет право регистрироваться пользователям из группы wheel, поэтому данное правило не будет препятствовать регистрации других пользователей. Если я не вхожу в эту группу и попытаюсь зарегистрироваться с системной консоли, это правило не запретит мне доступ.

Можно было бы попробовать создать два правила:

+:wheel: console
-:ALL:console

Это даст желаемый эффект, но этот вариант можно упростить, если использовать выражение ALL EXCEPT.

-:ALL EXCEPT wheel: console

Это правило отклоняет подключения быстрее. Кроме того, снижается вероятность ошибки администратора. Как правило, при создании списков в login.access лучше запрещать регистрации, а не разрешать их. Как только система дойдет до этого правила, она немедленно откажет в регистрации с консоли пользователям, не входящим в группу wheel.

Последнее поле в файле login.access, источник подключения, может содержать имена хостов, адреса хостов, номера сетей, имена доменов или специальные значения LOCAL и ALL.

Имена хостов

Имена хостов опираются на DNS или файл hosts. Если есть подозрение, что сервер имен подвергается атакам взломщиков, не стоит использовать доступ по имени соединяющегося хоста; злоумышленники могут назначить имени хоста любой IP-адрес и обмануть вашу систему при подключении. Тем не менее можно предпринять следующее:

-:ALL EXCEPT wheel:fileserver.mycompany.com

Пользователи из группы wheel могут входить в систему с fileserver, а все остальные — нет.

Адреса хостов и сети

Адреса хостов похожи на имена хостов, но они невосприимчивы к манипуляциям с DNS.

-:ALL EXCEPT wheel:192.168.1.5

Номер сети — это усеченный IP-адрес:

-:ALL EXCEPT wheel:192.168.1.

Такое правило позволит каждому члену группы wheel регистрироваться с машины, IP-адрес которой начинается с 192.168.1, а также запретит доступ всем остальным.

LOCAL

Самое сложное местоположение — LOCAL. Ему соответствует любое имя хоста без точки (обычно это хосты в локальном домене). Например, www.ahsolutefreebsd.com предполагает, что любой хост в домене absolutefreebsd.com соответствует LOCAL. Такая функциональность реализована на основе метода обратного преобразования адресов в DNS (глава 14), который более уязвим для мистификаций. Мой ноутбук может заявить, что его имя — humvee.blackhelicopters.org, но его IP-адрес соответствует записи обратного DNS, утверждающей, что он находится где-то в сети моего поставщика услуг Интернета. Машина в домене absolutefreebsd.com подумает, что моему ноутбуку присвоено имя хоста, принадлежащее другому домену, а значит, он не является локальным. Таким образом, я не могу применять LOCAL в качестве метода проверки.

Аналогичным образом, любой, кто владеет блоком IP-адресов, сможет дать им любые имена в записях обратного DNS. Поэтому ограничение LOCAL не особенно полезно в реальных условиях.

ALL и ALL EXCEPT

Выражение ALL соответствует всем хостам, a ALL EXCEPT — всем, за исключением указанных далее. На мой взгляд — это наиболее полезные выражения при построении правил, ограничивающих источники подключения. Например, если необходимо обеспечить доступ к системе только с двух рабочих станций, можно записать такое правило:

-:ALL EXCEPT wheel:ALL EXCEPT 192.168.89.128 192.168.170.44

Собрать все вместе

Назначение этих правил заключается в обеспечении политики входа в систему, которая соответствует вашей политике безопасности. Если вы оказываете услуги общего характера, но удаленный доступ к системе разрешается только для системных администраторов, однострочный login.access позволит предотвратить попытки входа посторонних пользователей:

-:ALL EXCEPT wheel:ALL

Это замечательно, если с подобными ограничениями можно жить и работать. Однако мне случалось работать с несколькими поставщиками услуг Интернета, которые использовали FreeBSD. Обычным клиентам не разрешалось регистрироваться на серверах, если в их учетных записях не был указан командный интерпретатор. Системные администраторы, а также администраторы DNS и веб-сервера (члены групп dns и webmasters) могли выполнять вход с удаленных рабочих мест. Но с консоли могли выполнять вход только системные администраторы.

-:ALL EXCEPT wheel:console
-:ALL EXCEPT wheel dns webmasters:ALL

При наличии этой записи пользователи не смогут войти в систему, если их не добавить в группу, которой разрешен доступ.

Ограничение на использование ресурсов системы

Существует возможность организовать более точное управление с помощью классов доступа. Описания классов доступа находятся в файле /etc/login.conf и определяют, какие данные и какие ресурсы могут предоставляться пользователям. Каждый пользователь закрепляется за определенным классом, и у каждого класса есть свои ограничения на доступ к системным ресурсам. Изменения ограничений для класса затрагивают всех пользователей, которые к нему принадлежат. Класс пользователя задается при создании его учетной записи. Изменить класс можно с помощью команды chpass(1).

Определения классов

По умолчанию login.conf начинается с класса default, который применяется для учетных записей, не относящихся к другим классам. По сути, этот класс предоставляет пользователям неограниченный доступ к системным ресурсам и больше подходит для приложений серверов с ограниченным числом пользователей. Если это соответствует вашим потребностям, не трогайте этот файл вообще.

Каждое определение класса состоит из последовательности операций присваивания значений переменным, которые определяют среду окружения пользователя, порядок учета и ограничения на системные ресурсы. Каждая запись в определении класса начинается и заканчивается двоеточием. Символ обратного слэша — это символ продолжения, он означает, что определение класса продолжается на следующей строке. За счет этого файл можно представить в удобочитаемом формате. Вот как может начинаться описание класса:

Этот класс называется default (1). Я показал три из нескольких десятков переменных в этом классе. Например, переменной passwd_format (2) присвоено значение md5 (3). Такие операции присваивания значений переменным и само имя класса составляют описание класса, и вы можете влиять на работу пользователя в системе, причисляя его к тому или иному классу.

Некоторые переменные login.conf не имеют значений; они изменяют свойства учетной записи своим наличием. Например, воздействие переменной requirehome определяется упоминанием ее в классе. Если эта переменная присутствует в определении класса, то для входа в систему пользователь обязан будет иметь домашний каталог.

:requirehome:\

После редактирования login.conf необходимо обновить базу данных login, чтобы изменения вступили в силу:

# cap_mkdb /etc/login.conf

Эта команда перестроит файл базы данных /etc/login.conf.db, который используется для ускорения поиска, как описанный ранее файл /etc/spwd.db. По умолчанию файл /etc/login.conf включает в себя несколько примеров классов пользователей. Чтобы понять, какие ограничения можно накладывать на пользователей в различных ситуациях, справляйтесь с этими примерами. В следующем разделе рассказывается о том, что можно устанавливать в классе доступа. Полный перечень доступных параметров в вашей версии FreeBSD можно найти на странице руководства login.conf(5).

Ограничения на ресурсы

Ограничения на ресурсы позволяют управлять объемом системных ресурсов, которые одновременно может задействовать один пользователь. Если к машине подключаются несколько сотен пользователей, а один из них решает скомпилировать OpenOffice.org, то этот пользователь может потреблять намного больше памяти и времени процессора, чем ему положено по справедливости. Если ограничить ресурсы, которые один пользователь может монополизировать одновременно, то система будет более отзывчивой к остальным пользователям.

В таблице 7.3 описаны переменные файла login.conf, отвечающие за ограничения ресурсов.

Таблица 7.3. Переменные login.conf для ограничения ресурсов

Переменная Описание
cputime Максимальное время процессора, которое может использовать любой процесс
filesize Максимальный размер одного файла
datasize Максимальный объем памяти, который может потреблять один процесс для хранения данных
stacksize Максимальный объем стека, доступный одному процессу
coredumpsize Максимальный размер дампа памяти
memoryuse Максимальный объем памяти, который процесс может заблокировать
maxproc Максимальное количество процессов, которые могут быть одновременно запущены одним пользователем
openfiles Максимальное количество открытых файлов на один процесс
sbsize Максимальный размер буфера сокета, который может задействовать приложение пользователя

Обратите внимание: зачастую ограничения на ресурсы привязаны к процессам по отдельности. Если каждый процесс получает 20 Мбайт памяти, а каждый пользователь может запускать 40 процессов, то тем самым вы разрешаете каждому пользователю получить 800 Мбайт памяти. Возможно, в вашей системе очень много памяти, но действительно ли так много?

Текущие и максимальные ограничения на ресурсы

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

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

Для задания текущего ограничения добавьте -cur к имени переменной. Для установления жесткого лимита добавьте -max. Например, для установления текущего ограничения на количество процессов, которые могут быть у одного пользователя, выполните следующее:

:mахproc-cur: 30:\
:mахргос-max: 60:\

Помимо наложения ограничений можно использовать функции учета ресурсов. Учет ресурсов не так уж важен сегодня по сравнению с временами, когда недорогой компьютер стоил десятки тысяч долларов, поэтому учет ресурсов в этой книге не рассматривается. Гораздо важнее иметь возможность накладывать ограничения на отдельного пользователя, чтобы не позволить ему потреблять больше процессорного времени, чем положено. Тем не менее полезно знать, что такая возможность существует.

Задание параметров среды по умолчанию

Существует возможность определять параметры среды в файле /etc/login.conf. Это лучше, чем устанавливать их в пользовательских файлах .cshrc или .profile, поскольку настройки в login.conf окажут влияние на все учетные записи пользователей, подключающихся после задания этих параметров. Некоторые командные интерпретаторы, такие как zsh(1), не просматривают упомянутые конфигурационные файлы, поэтому описание среды в классе позволит правильно установить значения переменных окружения для пользователей, работающих с такими интерпретаторами.

Каждое поле окружения распознает два специальных символа. Тильда (~) замещается домашним каталогом пользователя, а знак доллара ($) — именем пользователя. Следующие несколько примеров из класса default иллюстрируют их использование:

Например, переменной окружения MAIL присваивается значение /var/mail/<username> (1). Так же последний каталог в определении переменной PATH — это каталог bin в домашнем каталоге пользователя.

В таблице 7.4 перечислены типичные параметры настройки среды, которые используются в файле login.conf.

Комментарии запрещены.