Данные, собранные Performance Reporter помогут вам узнать то, какие пользователи используют какие ресурсы и проанализировать узкие места и другие проблемы производительности.
Вы можете собрать информацию о производительности с узлов под управлением AIX, Sun Solaris, и HP-UX. Вы можете легко использовать данные из базы данных Performance Reporter в других прикладных программах. Модель данных хорошо зарегистрирована и просто изменяется.
Безопасность
Система безопасности AIX соответствует уровню безопасности С2. Этот стандарт предъявляет к системе основные шесть требований:
· Должны быть введены четко сформулированные правила безопасности;
· Должны быть однозначно определены все пользователи и их права доступа;
· Все объекты должны быть помечены соответствующим уровнем безопасности;
· Система должна отслеживать все действия, связанные с защитой, и закрывать эту информацию;
· Система должна обеспечивать безопасность и быть способна доказать эффективность этого обеспечения;
· Система должна быть способна защитить сама себя.
Свидетельство на соответствие уровню безопасности не гарантирует того, что система защиты совершенна. Наличие свидетельства просто говорит о том, что система прошла тесты на соответствие уровню безопасности.
Набора средств для обеспечения безопасности, встроенных в AIX, вполне достаточно для реализации приемлемой политики безопасности коммерческих организаций. Важно только уметь правильно воспользоваться этими средствами.
Политика безопасности
"Безопасность - функция управления". Это утверждение повторяется при любом обсуждении проблем безопасности - и… часто игнорируется. Никакая комбинация аппаратных средств и программ защиты программного обеспечения не будет эффективна без соответствующей среды управления, включая все уровни управления.
Каждая организация нуждается в политике безопасности. Это утверждение может показаться очень простым, но оно должно однозначно быть понято каждым сотрудником в организации. Политика безопасности и её реализация обсуждалась во многих источниках. Постараюсь не повторять эти документы. Но необходимо ещё раз отметить то, что политика безопасности очень важна, так как очень просто ошибиться при установке защиты информационной системы без знания целей безопасности.
Элементы политики безопасности должны включать в себя ответы на следующие вопросы:
Границы безопасности между сотрудниками, группами, организацией и остальной частью мира. Для этого нужно иметь ответы на следующие вопросы:
· Какие типы данных должны быть ограничены для конкретных людей?
· Какие данные разделяется между отделами или другими группами?
· Что является доступным каждому в организации?
· Что является доступным для внешнего мира?
· Как должна организация разделена по группам (в смысле достижения целей безопасности)?
· Какие уровни безопасности необходимы для этих различных групп?
· Где раздел между удобством в работе и требуемой защитой?
· Какова стоимость безопасности?
· Что такое для вас приемлемая стоимость безопасности? (Затраты на администрирование и доставляемое неудобство пользователям - это также части общей стоимости безопасности).
· Какова стоимость потерянных, разрушенных или скомпрометированных данных?
· Сопоставима ли она со стоимостью затраченных средств на обеспечение безопасности?
· Кто будет управлять обеспечением информационной безопасности?
· Кто будет осуществлять контроль? Эти функции требуют времени и квалификации. Ведь пока нет таких интеллектуальных автоматизированных средств которые сами собой поддерживали бы необходимый уровень безопасности
· Как важно соблюдать политику безопасности сотрудниками?
· Каковы механизмы принуждения? Например, в некоторых организациях человека могут только пожурить за нарушение им требований безопасности. В других организациях этот человек был бы уволен немедленно за то же самое нарушение.
От кого защищаемся?
При слове "безопасность" чаще всего возникают образы защиты от промышленного шпионажа и хакеров. Но это лишь очень маленький элемент обеспечения информационной безопасности. Практика показывает, что основные проблемы защиты информации связаны больше с внутренними пользователями, чем с внешними. И главными проблемами являются:
1. Ошибки. Например, пользователь может ошибочно удалить файл. Защищенные важные файлы и хорошая процедура резервирования (которая является также элементом безопасности) уменьшат эти проблемы.
2. Обиженные служащие (или уволенные служащие). Они могут уничтожить, украсть и передать третьей стороне конфиденциальную информацию, внести заведомо неправильные данные, или могут просто напакостить в системе.
3. Любопытные служащие. Например, каждый из них хотел бы читать (и возможно изменять) многие служебные файлы и платежную ведомость.
4. Служащие "с отклонениями". Взлом системы безопасности является развлечением для некоторых людей. Без желания нанести вред. Однако, если конфиденциальная информация должна остаться конфиденциальной, она должна остаться таковой.
Политика безопасности должна исполнятся во всей организации. Не имеет никакого смысла в защите конфиденциального файла на одной системе, когда копия этого же файла может открыто читаться на другой системе.
Сколько нужно безопасности?
Слишком много безопасности может быть так же плохо, как и слишком мало. Соответствие самому строгому уровню безопасности вместе с применением множества средств обеспечения безопасности, при условии, что система неаккуратно спроектирована и плохо управляется, может привести к неэффективности защиты и сложности использования системы по её прямому назначению.
Необходимо помнить, что практически всегда повышение уровня безопасности системы требует увеличения времени и усилий администратора на управление им.
Компьютерные уровни защиты, определенные U.S. Department of Defence стали для большинства основными критериями при закупке систем. Этими уровнями по возрастанию, являются D, C1, C2, B1, B2, B3, и A.
Уровень "D" не имеет никаких функций защиты.
Уровни "C" имеют контролируемые средства управления защиты. То есть, пользователь решает, какие его ресурсы защищать и управляет (до некоторой степени) тем, как эта защита применяется.
Уровни "B" имеют обязательные средства управления защитой (наряду с другими дополнительными функциями). Средства управления автоматически применяются системой.
Уровень "A" является столь необычным, что имеется только несколько примеров его практической реализации.
Обратите внимание, что вышеупомянутые уровни относятся к изолированным системам и вообще игнорируют проблемы безопасной работы в сетях.
Установка системы уровня "B" автоматически не повысит уровень безопасности вашей системы. Вам понадобится значительно больше времени и умений для планирования и управления системой уровня "B", чем системой более низшего уровня.
Не приобретайте или не устанавливайте больше средств защиты чем те, которыми вы сможете управлять.
Общие дефекты защиты
В этой книге обсуждается много дефектов защиты AIX. Однако имеются три специфических дефекта, которые являются более важными, чем весь другие вместе взятые. Это:
1) недостаточно надежные пароли;
2) "программы устанавливающие userid";
3) недостаточные ограничения на доступ к директориям.
Проблема недостаточных паролей не уникальна для AIX. Почти каждый компьютерный пользователь уверен, что он может выбирать хорошие пароли. Но обычно это не так. Большинство нападений на UNIX системы осуществляется подбором пароля. И часто эти нападения удачны, потому что обычно требуется наличие только одного userid с недостаточно надежным паролем, чтобы обеспечить возможность для получения несанкционированного доступа к системе.
Однажды зарегистрировавшись в системе "злоумышленник" часто использует "программы устанавливающие userid" (обычно называемые suid), чтобы получить более широкий доступ к системе. Функция suid - не дефект (см.Биты доступа (Продвинутые)); она является необходимой частью UNIX. Нарушение безопасности вызывает неправильное употребление suid.
AIX не поддерживает suid для командных файлов оболочки (shell scripts). И это одно из основных отличий AIX от многих других UNIX систем, что является определенным расширением защиты.
Защита файлов (включая файлы, которые являются выполнимыми программами) вообще управляется битами разрешения, хотя доступны и другие средства управления. На практике, для надежной защиты файла требуется, чтобы кроме установки пользователем битов разрешения непосредственно на файл, были установлены соответствующие биты разрешения на директории в цепочке директорий ведущих к файлу.
Те пользователи, которые осторожны с битами разрешения для их файлов, являются часто небрежными (или не сознающими важность) в отношении установки битов разрешения на директории.
Эти три дефекта (недостаточные пароли, программы suid, и установка разрешений на директории) объясняют многие общие проблемы защиты UNIX.
Многие также читали об экзотических и сложных нападениях на различные системы. Такие нападения существуют, но они редки и требуют нетривиальной квалификации нападающего. Поэтому в этой книге мы сконцентрируемся на общих и стандартных элементах защиты для "обычной" системы AIX в "обычной" коммерческой среде.
Физическая защита
Физическая защита имеет несколько аспектов, включая:
· Доступ к компьютеру;
· Доступ к кабелю LAN;
· Доступ к привилегированным терминалам, типа "пульт оператора".
Проблемы физической защиты очевидны и мы не будем обсуждать их здесь.
Концепция безопасности AIX
Безопасность операционной системы AIX базируется на том, что каждому пользователю в системе ставится в соответствие уникальное имя, идентификатор пользователя (UID) и пароль. Когда пользователь подключается к системе, его UID используется для всех запросов на доступ. Идентификационный номер имеет также каждый процесс в системе. Когда создается любой файл, UID ассоциированный с процессом, который создал этот файл, ассоциируется с этим файлом. Только создатель или пользователь root могут изменить правила доступа к файлу.
Предопределены следующие пользователи: root - супер пользователь с максимально широкими полномочиями adm, sys, bin, ... - идентификационные номера используемые системой и которые нельзя использовать для входа в систему пользователям.
Пользователи, которым требуется доступ к одним и тем же данным или ресурсам, объединяются в группы. Каждая группа имеет уникальное имя и групповой идентификационный номер (GID). GID также ассоциируется с файлом при его создании.
Первоначально существуют две группы: system - для администраторов user - для обычных пользователей
Группы
Создание групп организует пользователей, которым необходим доступ к одним и тем же файлам или ресурсам системы. Руководство группами должно быть частью любой политики безопасности в организации. Определение групп для больших систем может быть очень сложным и находится вне контекста этой книги.
Каждый пользователь может принадлежать только к одной группе, а также быть членом нескольких групп. Пользователи будут часто принадлежать больше чем к одной группе, но членство в группах не должно быть чрезмерным.
Логично разделение пользователей на группы пользователей с административными функциями и прочих пользователей. Поэтому существуют три различные типы групп в системе:
Группы пользователей Люди, которым необходим доступ к одним и тем же данным, такие как пользователи, которые работают в одном отделе или над одним и тем же проектом.
Группы системных администраторов Системные администраторы автоматически являются членами группы system. Членство в одной из этих групп позволяет системным администраторам выполнять различные задачи системного администрирования без необходимости регистрироваться как пользователь root.
Предопределенные системные группы В системе существуют предопределенные группы. Например, группа staff является предопределенной группой для всех новых неадминистративных пользователей в системе. Другая предопределенная группа security обладает привилегиями для выполнения ограниченных функций администратора безопасности.
Системные предопределенные группы используются для контроля над работой некоторых подсистем.
Общие группы системы следующие:
system для основной конфигурации и поддержки стандартного аппаратного и программного обеспечения.
printq для управления очередями.
security управление парольной защитой и ограничениями
adm основные функции мониторинга системы
staff предопределенная группа для всех новых пользователей системы
audit для аудиторов в системе
Администрирование групп
Пользователь может быть членом многих групп и AIX будет для разрешения доступа к файлу автоматически искать все разрешения для этого пользователя в его группах. Ваше наиболее общее имя группы должно быть сделано заданным по умолчанию именем группы для новых пользователей. В AIX заданное по умолчанию имя такой группы - staff.
Для изменения наименования группы, заданной по умолчанию для новых пользователей, отредактируйте станзу pgrp в файле /usr/lib/security/mkuser.default. В этом файле содержатся значения по умолчанию для команд mkuser и smit. Например, чтобы заданная по умолчанию группа имела имя office, отредактируйте файл /usr/lib/security/mkuser.default следующим образом:
user :
pgrp = staff
на
user :
pgrp = office
Имеются также два типа групп в системе: административные группы и нормальные группы.
Группа администрации определена в файле /etc/security/group станзой admin. В каждой группе может иметься свой администратор группы. Это определено в строфе файла /etc/security/group.
Не запутайтесь с указанием административных прав. Если значения admin=true находится в /etc/security/group (см.Файлы /etc/group и /etc/security/group), то это указывает административную группу. Но admin=true в файле /etc/security/user (см.Файл /etc/security/user) означает, что пользователь имеет административные права для той специфической группы, которая указана в станзе adms файла /etc/security/group. С admin=true, пользователь может управлять той группой.
Включение пользователя в административную группу не имеет большого эффекта в AIX. Для небольших систем рекомендуется игнорировать административные группы и пользователей. В этих системах для выполнения управления пользователями нужно использовать права root. Большие же системы (более чем с 30 или 40 пользователями) могли бы нуждаться в администраторах групп.
Если ваша политика безопасности разрешает это, то самым простым способом выполнять управление группой могло бы стать разрешение администраторам группы выполнять команду su root. Если ваша политика безопасности не разрешает администраторам группы знать пароль root, то в этом случае можно использовать административную группу и её атрибуты.
В AIX включена группа, именованная security. Любой член этой группы может читать все файлы администрирования пользователями в каталоге /etc/security (см. Теневые файлы), и может выполнять многие из команд управления системой. С небольшим усилием, член группы security может получить полномочия root. Следовательно, только самые доверенные сотрудники должны быть в этой группе.
Стандартные userids
AIX имеет userid и группы, которые необходимы системе. Не изменяйте параметры этих пользователей и групп, если, конечно, Вы не очень уверенны в том, что Вы делаете :-). Никогда не входите в систему с любым из этих userid (за исключением root).
Идентификаторы пользователя, которые включены в систему (в форме, в которой они описаны в /etc/passwd) перечислены ниже. Эти идентификаторы используются для различных целей, типа монопольного использования файла и функций NFS. Все они, за исключением root, являются заблокированными для входа в систему в распределенной системе. (Они заблокированы паролем = * в /etc/security/passwd):
root:!:0:0:/:/bin/ksh
daemon:!:1:1::/etc:
bin:!:2:2::/bin:
sys:!:3:3::/usr/sys:
adm:!:4:4::/usr/adm:
uucp:!:5:5::/usr/spool/uucp
public:/usr/lib/uucp/uucico
guest:!:100:100::/usr/guest:
nobody:!:4294967294::4294967294::/:
lpd:!:104:9::/:
Новые пользователи, которых вы добавляете, будут значение по умолчанию в группу staff, если вы не изменили значение по умолчанию.
groupids, которые включены в систему - (в форме, в которой они появляются в /etc/group):
system:!:0:root
staff:!:1:
bin:!:2:root,bin
sys:!:3:root,bin,sys
adm:!:4:bin,adm
uucp:!:5:uucp
mail:!:6:
security:!:7:root
cron:!:8:root
printq:!:9:lpd
audit:!:10:root
ecs:!:28:
nobody:!:4294967294:nobody
usr:!:100:guest
Настоятельно не советуется назначать пользователей в любую из перечисленных выше групп (за исключением staff), если, конечно, вы не уверенны относительно последствий таких действий. Некоторые из этих групп (типа system, bin, security, cron) - владельцы совокупности многих важных файлов и директорий. Включение пользователя в любую из этих групп, с небольшим усилием, может скомпрометировать любые средства информационной безопасности в системе.
Пользователи
Все пользователи в системе, в соответствии с их правами, разделены на три категории:
1. пользователь root;
2. пользователи с административными правами (группы security, system, printq, cron, adm, audit). Особого внимания заслуживают пользователи включенные в группу security, так как они могут добавлять/удалять/изменять других пользователей или группы;
3. обычные пользователи.
Для защиты пользователей из административной категории от некорректных действий пользователей группы security, только пользователь root может добавлять/удалять/изменять пользователей и группы административной категории.
Для того чтобы добавить любого пользователя в административную категорию следует сделать следующее:
Набрать команду: # cat /etc/security/user и в станзе описания пользователя внести следующее:
user1: admin=true
Переменная PATH
PATH - относящаяся к окружению переменная, используемая текущей оболочкой при поиске исполняемых файлов (команд). При использовании нормальной оболочки, пользователь может изменять PATH в любое время. Не имеется никакого приемлемого способа предотвратить такие изменения. (Ограниченная оболочка, обсужденная в Trusted Computing Base (TCB) не разрешает изменения для PATH.)
Одна из целей защиты состоит в том, чтобы защитить root (или любого другого пользователя) от выполнения поддельной программы. Например, если /tmp (незащищенный каталог) - первый элемент в PATH и если злоумышленник поместит программу под именем su в /tmp, эта программа su будет выполнена вместо правильной программы su системы.
Дефект PATH - простое понятие и вы, как администратор системы, должны понять это. PATH пользователя обычно устанавливается (используя профиль системы и профиль пользователя (если они существует)), когда он регистрируется в системе. Домашней директорией пользователя root обычно является директория root и файл /.profile (если он существует) будет выполнен, когда root регистрирует в систему. Если же мы получаем полномочия root используя команду su профиль root (это верно и для получения полномочий любого другого пользователя командой su) автоматически не выполняется. (Использование флажка "-" с командой su заставит профиль целевого пользователя быть выполненным, но это может иметь последствия на текущем пользователе. Обычно, флажок "-" не используется с su.)
Например, если вы регистрируетесь в системе как обычный пользователь и затем даёте команду su root, вы продолжаете использовать профиль (и PATH), установленный первоначальным профилем пользователя. Это может быть источником серьезных нарушений защиты, подобных этой:
1. Пользователь (желающий получить пароль root) пишет маленькую программу на C, выводящую сообщения, аналогичные сообщениям команды su. То есть, эта программа попросит вас ввести пароль root.
2. Пользователь компилирует и линкует эту программу и помещает её в свою библиотеку.
3. Пользователь изменяет свой PATH таким образом, чтобы первой директорией в поиске была его личная (home) директория.
4. Пользователь просит администратора решить какую-нибудь проблему, решение которой, вероятно, требует прав доступа root.
5. Администратор приходит к терминалу пользователя и использует команду su, чтобы получить полномочия root. Когда администратор вводит команду su, система ищет программу с именем su сначала в личной директории пользователя (как установлено в PATH пользователя) и находит подделанную программу su и выполняет её.
6. Программа su пользователя запрашивает ввод администратором пароля root, сохраняет пароль в невидимом файле, посылает сообщение об ошибке о вводе неправильного пароля и стирает саму себя.
7. Администратор думает, что он ввел неправильный пароль и пытается снова выполнить команду su root. Сейчас всё функционирует нормально, так как подделанная программа уже удалена и сеанс продолжается как обычно.
8. Пользователь позже читает пароль root из невидимого файла и может войти в систему как root.
Это - классическое нападение "Троянского коня", и оно сработало, потому что администратор выполнил команду su используя неправильный PATH.
Для защиты от таких нападений на систему безопасности, рекомендуется следующее:
1. Администратор, при получении полномочий root, если он работает в среде другого пользователя, должен всегда вводить полное имя пути команд. Это позволит избежать использования PATH пользователя.
2. В PATH для обычного пользователя первыми в пути поиска должны быть стандартные директории системы, перед текущей директорией или специфической директории $HOME. Заданный по умолчанию путь (установлен значением по умолчанию) для AIX: PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:$HOME/bin:/usr/bin/X11:/sbin:. Поддиректории внутри /usr содержат большинство команд AIX, используемых обычными пользователями. Директория /etc содержит символьные ссылки на команды в более удаленных директориях. Обратите внимание, что сначала ищутся библиотеки системы. И только после этого поиска просматриваются программы в $HOME/bin. "Точка" в последней позиции PATH указывает на поиск в текущей директории.
Игнорируя малые элементы (X11 и /sbin), порядок поиска PATH следующий: директории системы, директория программ пользователя(/$HOME/bin) и текущая директория. Это - безопасный порядок поиска, хотя можно спорить о том, должна ли текущая директория ("точка") быть в пути поиска.
Блокировки по времени
Блокировки по времени используются, чтобы автоматически блокировать оболочку, которая неактивна слишком долго. Функция блокировки по времени обеспечивается не для базисного ядра AIX, а для оболочек AIX.
По умолчанию блокировка по времени не включена. Для установки блокировки по времени Korn shell использует переменную TMOUT, а Borne shell использует переменную TIMEOUT. Вы, как администратор, должны установить одну или обе из этих переменных, если Вы хотите автоматически блокировать оболочку после чрезмерного неактивного состояния.
Настоятельно рекомендуется использовать эту функцию, потому что терминалы без присмотра - серьезное нарушение защиты. Например, добавьте строки в файлы /etc/profile или к /etc/security/.profile:
TMOUT=45
TIMEOUT=45
export TMOUT TIMEOUT
Блокировка по времени выражена в минутах. Если пользователь запускает несколько оболочек (например, запуская команду ksh неоднократно), оболочки будут блокированы по времени в обратном порядке.
Период блокировки по времени - переменная относящаяся к оболочке или к окружению и она может быть изменена каждым пользователем. Вы не можете предписывать стандартное для всех значение (если только ваши пользователи не знают, что они могут изменять значение периода блокировки по времени).
Подсказки (Prompts)
Вы можете устанавливать подсказку оболочки, чтобы показать на экране информацию о текущей директории. Для пользователей оболочки Korn, это выполняется путём добавления следующих двух строк в профиль $HOME/.profile:
PS1='$PWD $ ' (используйте одиночные кавычки)
export PS1
Это изменение обеспечивает выведение пути и имени текущей директории, сопровождаемых традиционным символом "$". К сожалению, эта простая методика вводит в заблуждение, если пользователь выполняет команду su root. "$" будет всё еще появляться вместо символа "#" который является традиционным для su root.
Этого можно избежать, не используя такую подсказку для пользователей, которым часто приходится выполнять команду su root, или используя команду su с флажком "-".
Подсказка, показывающая путь текущей директории, полезна для многих пользователей, особенно, если они обычно работают со многими директориями.
Не имеется более никаких дефектов защиты при использовании подсказок (кроме как вышеуказанного введения в заблуждение администратора), но информативная подсказка может уменьшать количество ошибок пользователя.
Отключение userid root
Редко имеется необходимость для регистрации в системе пользователем root. Большинство "несчастных случаев" в системах UNIX часто вызваны использованием root, как стандартного userid. Поэтому, после того, как ваша система сконфигурирована, вы можете отключить возможность входа в систему как root. Уполномоченные пользователи (те, кто знают пароль для root) могут пользоваться командой su root после того, как они вошли в систему под их обычными userids.
Отключение root легко выполняется с помощью SMIT:
smit -Security and Users --Users
---Change / Show Characteristics of a Userid
* User NAME [root]
...
Another user can SU TO USER? [true]
...
User can LOGIN? [false] <--
User can LOGIN REMOTELY? [false] <--
Не отключайте пользователя root, напрямую редактируя файл /etc/passwd и изменяя поле пароля. Такое действие запретит вам использование полномочий root с помощью команд su или telnet.
Аудит безопасности
Файл /var/adm/sulog содержит информацию в ASCII формате о дате, времени, имени системы и имени пользователя, которые входили в систему. Этот файл можно просмотреть командами pg, more или cat. Этот файл также фиксирует тот факт, была ли попытка входа в систему удачной или нет.
Файл /etc/utmp содержит информацию о текущих пользователях системы.
А файл /var/adm/wtmp содержит информацию о времени нахождения пользователей в системе (фиксирует время входа и выхода из системы). Для просмотра этой информации используйте команду who file_name. Команда who без параметров показывает содержимое файла /etc/utmp.
Для просмотра хронологического списка входов и выходов из системы используется также команда last. Например, команда last root выдаст информацию обо всех входах и выходах из системы пользователя root, а команда last reboot покажет время прошедшее между перезагрузками системы.
Существует также еще один важный файл, просматриваемый командой who. Это файл /etc/security/failedlogin, из названия которого следует, что в него заноситься информация каждый раз при неправильном вводе имени и/или пароля при входе в систему. Нераспознанные имена пользователей записываются как UNKNOWN.
Проверка пользовательского окружения
Для поддержки системы безопасности вы можете воспользоваться некоторыми "проверяющими" командами (grpck, usrck, pwdch, sysck, tcbck) и "списочными" командами (lsuser и lsgroup) доступными для использования пользователю root (или любому пользователю из группы security).
Команда grpck
Команда grpck проверяет для всех пользователи, поскольку члены группы определены как пользователи, что их gid уникальны, и что имя группы правильно сформировано. Также выполняются другие небольшие проверки. Флажок -t заставляет команду сообщать об ошибках и спрашивать относительно разрешения об их устранении: grpck -t ALL
Эта команда проверяет среду группы, и, если Вы отвечаете Yes на запрос, будут стёрты userids, которые не существуют или для которых станзы в файле /etc/security/user имеют противоречивые данные.
Команда usrck
Команда usrck проверяет много параметров области определения userid. Флажок -t заставляет команду сообщать об ошибках и спрашивать относительно разрешения об их устранении. В некоторых случаях команда отключит userid, добавляя дату окончания в область определения пользователя. На данные пользователя эта команда не воздействует. Пользователя можно допустить в систему снова, удаляя добавленную дату окончания (используя SMIT или непосредственно редактируя файл /etc/security/user).
usrck -t ALL Никогда не пробуйте исправлять userid root, используя эту команду. Если Вы хотите попробовать это сделать, пожалуйста сначала прочитайте о восстановлении root userid (см.Восстановление root userid).
Команда pwdck
Команда pwdck проверяет опознавательные станзы в файлах /etc/passwd и /etc/security/passwd. Если что-то неправильно, стандартным действием этой команды является удаление станзы или создание станзы /etc/security/passwd с * (звездочкой) в поле пароля. Запустив эту команду нижеуказанным синтаксисом вы получите сообщение о проблемах и отчет об их фиксации: pwdck -t ALL Команда pwdck не проверяет определенные правила задания пароля, типа minalpha, minother, и lastupdate.
Команды lsgroup и lsuser
Эти команды используются SMIT, но Вы можете также использовать их непосредственно. Прямое использование может быть более удобно, когда вы хотите помещать их вывод в файл, например так:
lsgroup -f ALL >> /tmp/check lsuser -f ALL >> /tmp/check
В форме, показанной выше, эти команды создают файл /tmp/check и пишут в него свой вывод.
Эти команды отображают большинство информации необходимой для управления пользователями и группами. Эти команды могут использоваться любым пользователем, но намного больше информации отображается, когда они используются пользователем root (или любым членом группы security).
Команда lsuser непосредственно полезна при использовании root для специфического пользователя, например: lsuser joe Эта команда отобразит несколько строк, содержащие информацию управления для пользователя joe. Когда lsuser используется с операндом ALL, информация отображается для всех пользователей в системе. Доступны несколько опций форматирования.
Команда tcbck
Эта команда описана подробно в Trusted Computing Base (см.Trusted Computing Base).
Функции Ревизии (Аудита)
Когда вы устанавливаете AIX, подсистема контроля по умолчанию не устанавливается. Подсистема ревизии (аудита) обеспечивает средства, чтобы прослеживать и записывать относящуюся к защите информацию. Вы можете использовать эту информацию, чтобы обнаружить потенциальные и фактические нарушения стратегии защиты.
Вы (администратор, действуя как root) можете конфигурировать и управлять подсистемой аудита. Ряд команд, файлов управления, и параметров взаимодействует, чтобы управлять ревизией. Они могут быть для вас сложными.
Следующие описания концентрируются на базисном использовании и принимают, что вы используете контрольный файл управления, поставленный с AIX, только с минимальными изменениями.
Когда запущена контрольная подсистема, она ревизует (то есть генерирует запись вывода) для событий и объектов.
Могут быть определены два различных режима записи: BIN и STREAM.
Контрольные События
Событие - выполнение определенного действия, которое создает директорию или модифицирует пароль. Обнаружение События распределено через AIX (внутри доверенных модулей). Список всех определенных событий ревизии AIX дан в Контрольном Событии (вы можете добавлять контрольные события для ваших собственных программ, и расширять этот список, но это было бы необычно). Отчет включает имя события, успех события, и специфические данные для этого вида событий. Через различные контрольные средства управления вы можете выбирать, какие из этих событий вы хотите активизировать и записывать.
Вы должны минимизировать количество отслеживаемых событий, насколько это возможно. Запись всех возможных событий для каждого пользователя в системе может произвести к генерированию огромного количества данных и значительно понизит эффективность всей системы. Причем, администратор системы или безопасности просто физически не смогут разобраться с таким "обвалом" контрольной информации за приемлемый срок.
Ревизия События ВСЕГДА связывается с userid (или userids). Например, вы можете отслеживать создание директорий пользователем joe.
Имеются приблизительно 130 различных контрольных событий, встроенных в AIX. Контрольные события сгруппированы в классы. Имена классов произвольны.
Контрольные Объекты
В дополнение к отслеживанию событий, вы можете ревизовать объекты. Практически, - следить за файлами.
Вы можете контролировать три файловые операции: чтение, запись и выполнение. Объекты не связаны с пользователями.
Механизм для ревизии объекта генерирует псевдособытия, и этот процесс работает очень подобно ревизии событий. Вы можете легко добавлять дополнительные файлы, включая ваши файлы прикладных программ, в список контрольных объектов, расширяя файл /etc/security/audit/objects.
Команды аудита
Имеются пять разновидностей команд аудита:
· Audit start - используется для активизирования подсистемы контроля. Это - единственно правильный способ начать ревизию.
· Audit shutdown - прекращает работу подсистемы контроля, производится обработка заключительных записей BIN (если необходимо) и удаляется файл /audit/auditb, который используется как "активный" индикатор контрольных моду-лей.
· Audit off - временное приостановление ревизии. Например, при контрольном закрытии системы нет необходимости использовать ревизию.
· Audit on - включение подсистемы контроля после временного ее выключения командой audit off.
· Audit query - отображение состояния подсистемы ревизии.
Ограничения доступа к файлам/директориям
Существуют несколько битов доступа (разрешения), ассоциированные с файлом или директорией.
Стандартные ограничения r (read), w (write) и x (execute) определяют три уровня доступа для пользователя (владельца), группы (group) и остальных (others). В добавление к этим трем ограничениям существуют три бита доступа известные как SUID (set UID), SGID (set GID) и SVTX (sticky bit).
Бит SUID, установленный на исполняемом файле, означает, что при выполнении этого файла процесс выполняется с эффективным идентификатором пользователя (UID) владельца файла. SUID не поддерживается для командных файлов оболочки (shell scripts). Бит SUID никак не относится к директориям.
Бит SGID, установленный на исполняемом файле, означает, что при выполнении исполняемого файла процесс выполняется с эффективным групповым идентификатором (GID) группы владельца файла. Бит SGID, установленный для директории означает что каждый файл или директория создаваемые в этой директории имеют те же групповые разрешения что и первичная группа пользователя, создающего новый файл/директорию. Бит доступа Файл Директория
r пользователь может читать содержимое файла пользователь может просматривать содержимое директории
w пользователь может изменять содержимое файла пользователь может создавать файлы и перемещать файлы в директорию
x пользователь может использовать имя файла как команду пользователь может входить (cd) в директорию и помещать её в PATH
SUID программа выполняется с эффективным UID владельца -
SGID программа выполняется с эффективным GID владельца файлы, созданные в директории наследуют принадлежность к той же группе, что и директория
SVTX - для удаления файла в директории пользователь должен быть владельцем файла или директории
Чтобы интерпретировать поля разрешений, выдаваемых, например, командой ls будет полезна нижеследующая схема:
Файловая защита AIX
Файловая защита - наиболее очевидный элемент защиты для большинства пользователей AIX. Базисными элементами, управляющими защитой файла в локальной системе являются:
· Биты разрешения, связанные с файлом.
· Биты разрешения, связанные с директорией, содержащей имя файла.
· Биты разрешения во всех директориях в пути к файлу.
· Списки разрешений ACL.
· Владелец файла.
· Группа-владелец файла.
· Владелец и группа-владелец директории, в которой размещен файл.
· Владельцы и группы-владельцы всех директорий высшего уровня в пути к файлу.
· Программы, выполняющиеся с эффективным userid пользователя root.
Частные файловые системы
Если вы создаете дополнительные файловые системы, рекомендуется, чтобы точки монтирования директорий имели биты разрешения -rwx ------- (восьмеричный 700).
Переносимые файловые системы (которые являются обычно "частными"), имеют уникальный дефект защиты. Когда их примонтируют, они функционируют как нормальные файловые системы, включая функции suid (и особенно suid root).
Пользователь мог бы взять свою переносимую файловую систему, добавить suid-программы root. Когда эта файловая система установлена на вашей системе, все эти suid-программы root могли бы быть агрессивными.
Администратор имет некоторый контроль над установкой частных файловых систем (Одна из опций mount - nosuid. Рекомендуется всегда использовать эту опцию при установке переносимых файловых систем (включая CD-ROM), и (возможно) при установке любой частной файловой системы).
Inodes и Links
Нормальные файловые системы UNIX (включая JFS AIX) используют уровень косвенного управления файлами, который обычно скрывается от пользователя.
Администратор должен понимать некоторые базисные элементы косвенного управления, так как они важны для защиты файлов.
Доступ к данным файла в UNIX - обычно подобен такой процедуре:
запись в директории --> inode --> блоки данных
То есть запись для файла в директории не указывает на данные файла. Она указывает на inode, который, в свою очередь, указывает на данные.
Биты разрешения защиты относятся к inode, а не к записи для файла в директории. Запись в директории содержит "имя" для файла, типа /u/trial/data.
inode имеет номер идентификации, но не "имя" файла.
В этом примере, одиночный файл (основанный на inode 317 внутри некоторой файловой системы) имеет три директории "связи". Тот же самый файл имеет три очень различных "имени". Биты Разрешения (и UID и GID) сохранены в inode. Вызов к файлу через любое из имен будет обеспечивать те же самые разрешения и средства управления владельца. Эти имена дополнительного пространства обеспечиваются символическими связями. (Символическая связь может функционировать между различными файловыми системами, и не удаляется, если адресат inode удален.
Жесткая связь работает только внутри конкретной файловой системы и может быть элементом управления в удалении данных файла и inode.)
Подобные связи могут существовать и на уровне директории (т.к. директория - частный случай файла). Например, директория /xxx могла бы быть символически связана с директорией /etc. Это означает, что файл /xxx/my/data - на самом деле является файлом /etc/my/data. К одному и тому же самому файлу обращаются в обоих случаях, хотя используются различные структуры директорий. Значение защиты связей директорий обсуждены позже.
Монопольное использование
Каждый файл (включая директории) имеет владельца и группу. Владелец и идентификаторы группы владельца (UID и GID) сохранены в inode. Изначально владелец это пользователь, который создал файл. Группа - текущая группа владельца, когда он создаёт файл. Пользователь root может изменять владельца файла, используя команду chown, и может изменять группу владельца с командой chgrp.
В AIX, обыкновенные пользователи не могут использовать команды chown или chgrp, потому что эти функции могут косвенно привести к дефектам защиты. В некоторых версиях UNIX, эти две команды доступны обычным пользователям.
Обратите внимание, что монопольное использование соответствует UID (владельца) и GID (группы владельца), а не его userid и groupid. Если userid (и его соответствующий UID) удален из системы, файлы, принадлежащие этому UID остаются в системе. Удаление userid не удаляет его файлы. Однако, в этом случае файлы, как кажется "не имеют" владельца. Но как только другой, позже назначенный userid, получит тот же самый UID, то он станет владельцем всех файлов, связанных с этим UID.
Если вас касается эта проблема, вы можете блокировать счет пользователя вместо того, чтобы удалить его.
Вы должны также понять, как на монопольное использование файла воздействуют команды mv и cp (перемещения и копирования). Команда копирования cp всегда создает новый файл, и пользователь который дал эту команду становится владельцем нового файла. Конечно, этот пользователь должен иметь достаточные разрешения на чтение исходного файла.
Если команда перемещения mv используется, чтобы переместить файл внутри файловой системы, монопольное использование файла не изменяется. Пользователь команды mv должен иметь разрешение на запись в целевой директории, и достаточные разрешения на чтение исходного файла. Если команда mv используется, чтобы переместить файл в другую файловую систему, новый файл создаётся и текущий пользователь становится владельцем файла. Пользователь должен иметь разрешение на запись и в исходной директории (чтобы удалить файл) и в целевой директории (чтобы создать новый файл). Он должен также иметь соответствующие разрешения на чтение для источника.
Биты доступа (Базовые)
Файлы (и директории) имеют биты доступа. Они иногда называются битами "режима", но мы будем использовать термин "биты доступа" или "разрешения".
Имеются 12 битов доступа:
· Три бита системы (которые непосредственно не отображаются);
· Три бита владельца, которые определяют то, что разрешается делать владельцу;
· Три бита группы, которые описывают что разрешается делать членам группы владельца;
· Три всеобщих бита, которые описывают то, что разрешается делать любым другим пользователям.
Биты доступа часто отображаются как девять битов (три старших системных бита отображаются специальными способами).
Разрешения - не являются иерархическими; то есть разрешение на запись или на выполнение не включают в себя разрешения на чтение.
Биты доступа часто записывают в восьмеричном формате. Восьмеричный формат удобен, так как первая цифра в такой записи разрешений показывает разрешения для владельца, вторая цифра - разрешения для группы владельца, и третья цифра - разрешения для остальных пользователей.
Команда ls
Команда ls - вероятно одна из наиболее важных команд для администратора безопасности. Вы должны понять детализированную информацию, которую это отображает. AIX также обеспечивает команду li, которая является очень подобной ls.
Предлагается, чтобы вы концентрировались на команде ls, так как это - стандарт во всех системах UNIX, и обучаться, чтобы использовать несколько из факультативных флажков.
Базисная команда ls отображает список файлов в текущем каталоге и не отображает больше ничего. Для получения большого количества информации, Вы будете обычно использовать одну из сле-дующих форм:
· ls -al
· ls -ld
· ls -l /some/file/name
· ls -ld /some/directory/name
Первая форма, ls -al, отображает информацию относительно всех файлов в текущем каталоге, включая "скрытые" файлы (чьи имена начинаются с периода(точки)).
Вторая форма, ls -ld, отображает информацию относительно текущей директории.
Третья форма, ls -l /some/file/name, отображает информацию относительно специфического файла.
Последняя форма, ls -ld /some/directory, отображает информацию относительно определенной директории.
Биты установки UID, установки GID, и sticky ("липкие") биты описаны далее.
Userid владельца показывается всеми длинными формами команды li.
Не забывайте, что владелец файла (или директории) может изменять любой из атрибутов файла за исключением имен группы и владельца. Их может изменять только root.
Inode содержит UID и GID владельца, не имена. Если UID (или GID) больше не зарегистрирован в файлах /etc/passwd (или /etc/group), вместо имени отображается номер (UID или GID).
Биты доступа (Продвинутые)
UNIX использует 12 битов доступа. Из них, девять - базисные r/w/x разрешения для владельца/группы/остальных. Три остающихся бита несколько более сложны. Это:
1. Бит установки UID (или suid);
2. Бит установки GID (или sgid);
3. Sticky (или "липкий") бит (бит svtx).
Эти биты критичны для средств управления защиты, и используются для изменения обычных разрешений "rwxrwxrwx". Для целей просмотра, эти биты изменяют три бита "x" в обычном просмотре.
Suid бит отображается, изменяя бит "x" для владельца "rwx" на "s", и т.д. Suid бит означает, что программа выполнится с полномочием UID владельца файла. (Исполняемые файлы обычно выполняются с полномочиями UID того пользователя, который зарегистрировался в системе и имеет права на выполнение данного файла.)
Например:
-r-sr-xr-x 1 root sys 3254 Jun 1 11:30 myprog
Файл myprog имеет набор битов suid. Если я (зарегистрированный в системе как пользователь alex) выполняю myprog, то эта программа выполнится с полномочием root. Так как root может обходить почти все средства управления защиты, такое средство могло бы быть опасно.
Например, в приведенном примере, myprog могла бы быть копией оболочки (или чем-то подобным). Выполняя myprog (с suid root), я действительно стал бы root. Я мог бы вводить любую команду системы, использующую эту оболочку, и эти все команды выполнятся с полномочиями root.
Такая ситуация (оболочка с suid root) является мечтой "злоумышленников". Вот почему в AIX сделано так, что suid-бит не может быть установлен для оболочки и ее командных файлов.
Эти биты установлены с командой chmod, используя или символические операнды или восьмеричный операнд с 4 цифрами.
Suid бит может быть установлен (использование команды chmod) только владельцем файла или root. Он автоматически удаляется при копировании командой cp.
Не имеется никакой прямой возможности для обычного пользователя, чтобы создать файл suid root.
Функция suid может использоваться иными владельцами кроме root. Это может использоваться, например, для того чтобы гарантировать, что к файлу обращаются только некоторой программой.
Например:
-rw------- 1 alex eng 5432 Jun 2 13:45 mydata -r-sr-xr-x 1 alex eng 2345 Jun 1 11:30 myprog
В данном примере любому пользователю разрешено запускать программу myprog. Но только userid alex может обращаться к mydata. Так как любой может выполнять myprog, и так как myprog использует suid, чтобы выполниться как alex, любой пользователь может обращаться к mydata только, выполняя myprog.
Типичная система AIX имеет несколько сотен программ suid root. Администратор многопользовательской системы должен гарантировать, что любые добавления (новые программы, которые suid root) получены из доверенного источника, - доверенные про-граммы.
В AIX имеются средства, который может помочь управлять доверенными программами (см.Trusted Computing Base).
Бит установки GID (sgid) работает точно так же как функция suid, используя тождество группы файла вместо тождества владельца. Sgid бит имеет специальное значение, когда используется с директорией, где он определяет, как назначено групповое монопольное использование для новых файлов.
AIX игнорирует suid и sgid биты при выполнении сценариев оболочки. То есть только компилируемые "программы" объектного кода могут быть suid к другому UID для выполнения. Некоторые системы UNIX разрешают сценарии оболочки к suid.
В принципе, это полезно. Практически, это очень опасно и было удалено из AIX.
Липкий бит используется для многих целей. В более ранних системах он использовался для указания того, что программа должна сохраниться в памяти после выполнения, чтобы улучшить эффективность системы. Эта функция не используется в современных системах UNIX. Взамен, она используется для директорий, чтобы еще более ограничить возможность изменять входы в директории.
В нормальной директории (без липкого бита), любой пользователь с доступом для записи может перемещать или удалять файлы в ней. Это - серьезный дефект для таких директорий, как, например, /tmp, которая являются всеобще-перезаписываемой. Когда липкий бит установлен, только владелец файла может удалить свой файл, даже если директория всеобще-перезаписываемая. (Конечно, владелец директории и root может также удалять файлы из нее.)
Обратите внимание, что любая информация защиты, эффективная в конкретной директории - не относится к поддиректориям; каждая директория повинуется только собственным битам доступа.
Разрешения (для файлов или директорий) не накопляются. Обычно, поле владельца обеспечивает большое количество разрешений чем поле группы, и поле группы большим количеством разрешений чем поле для остальных, но это не обязательно.
Или пример:
-r--rw-rwx 1 alex xyz 3210 Jun 3 15:15 mystuff
Файл mystuff имеет довольно необычные, но имеющие силу, разрешения. Владелец (alex) не может писать или выполнять этот файл. (Он может изменить разрешения, конечно, и добавить большее количество разрешений для себя, но, в данный момент, он не может писать или выполнять файл.) А любой член группы xyz может читать или писать файл. Кто-либо еще (кроме владельца и любых членов группы xyz) может читать, писать, или выполнять файл.
Установка различных разрешений, назначенных владельцу, группе, или остальным - может служить инструментом ограничения. Владелец, например, не рассматривается частью "остальных".
Этот аспект может использоваться, чтобы исключить некоторых пользователей от доступа к файлу. Создав новую группу, содержащую всех пользователей, которые будут исключены, групповой владелец файла затем может быть изменен на это новое имя группы. Разрешения новой группы устанавливаются в "---". В результате - никакой член группы не может обращаться к файлу, даже если файл имеет полный доступ для всех остальных.
Переменная umask
Каждый файл (и директория) имеют биты разрешения. Владелец может изменить их с командой chmod. Начальный, заданный по умолчанию, набор разрешений, когда файл создан, управляется относящейся к окружению переменной umask.
По причинам, возвращающимся к ранним дням UNIX, значение umask используется нечетным способом. То есть заданные по умолчанию разрешения устанавливаются, принимая разрешения ("rwxrwxrwx" (или восьмеричный 777) для директорий, или "rw-rw-rw-" (или восьме-ричный 666) для обычных файлов) и удаляя биты разрешения, определенные в umask (которая всегда выражается в восьмеричном формате).
Значение по умолчанию umask - 022. Следовательно, заданные по умолчанию разрешения: 666 удаляя 022 = 644 = rw-r--r-- (для файла) 777 удаляя 022 = 755 = rwxr-xr-x (для директории)
Для большей безопасности рекомендуется вместо значения 022 использовать значения 027 или 077: 666 удаляя 027=640=rw-r----- (для файла) 777 удаляя 027=750=rwxr-x--- (для директории)
umask - относящаяся к окружению переменная, которая может быть изменена пользователем с командой umask (который является командой оболочки).
Не имеется никакого способа предписать стандартное значение для пользователей. Различное значение по умолчанию может быть установлено размещая команду umask в файле $HOME/.profile пользователя. Однако, пользователь может изменить это значение в любое время.
Начальное значение umask пользователя может быть установлено через SMIT. Вы можете проверять ваше значение по умолчанию с командой umask (без операнда).
Файловые временные штампы (Timestamps)
Системы UNIX, включая AIX, поддерживают три временных штампа (timestamps) для файлов (включая директории). Они могут быть важны для решения вопросов защиты. Timestamps:
1. atime. Это - время последнего обращения к файлу. В действительности, это - время последнего открытия файла.
2. ctime. Это - время последнего изменения inode для файла. (Это - не время создания, если, конечно, создание файла не было последним событием для него) inode изменяется, всегда, когда изменены разрешения, изменен владелец, изменен размер файла (число кластеров), и т.д.
3. mtime. Это - время последнего изменения содержания файла. Это вообще означает, что файл был открыт для вывода. Это время может легко управляться root.
Длинные формы команды ls обычно вносят в список mtime. Флажок -c может исполь-оваться, чтобы взамен внести в список ctime. Флажок -u может использоваться, чтобы внести в список atime. Команда может ссылаться все три timestamps.
Команды ACL
AIX имеет дополнительную функцию защиты для файлов. Это - так называемый список управления доступа (ACL). Эта функция - не стандартная часть "традиционного" UNIX. Современные системы UNIX обычно имеют функцию ACL-типа, но команды и функциональные возможности отличаются в различных системах.
ACL в AIX может обеспечивать намного более детальное управление доступом, чем с использованием битов доступа. Обычно, явное управление с помощью ACL не используется для АРМ. Это может использоваться внутри специфических прикладных программ на серверах.
Каждый файл (и директория) имеет "базовый список доступа" так как стандартные биты доступа (старый термин) являются основой ACL (новый термин). Расширенные функции ACL обычно просто называются функциями ACL.
Базовые разрешения
Основные разрешения показываются acl-касающимися командами в следующем формате:
атрибуты: SUID, or SGID or SVTX в любой комбинации базовых разрешений:
владелец (имя): rw
группа (группа): r-x
остальные: -wx
Где: SUID означает setuid SGID означает setgid SVTX означает Savetext (липкий бит)
