использования CPU.
Команда netpmon покажет трафик узла на
канальном, сетевом и транспортном уровнях (протоколы
TCP и UDP). Эта команда может также обнаружить
трафик в другие сети и отображать сетевую
статистику трафика сортируя информацию по
узлам.
Для канального, сетевого и транспортного
уровней: сетевые анализаторы
При специфических проблемах для изучения
содержания пакетов данных в сети вы можете
использовать анализатор протокола.
Анализатор протокола фиксирует полную
структуру сетевых данных, без связи с
используемыми протоколами или с сетевой
операционной системой. Он обрабатывает
структуру как необработанные данные.
Доступны несколько коммерческих пакетов.
Они будут фиксировать структуру данных и
декодировать их согласно типа протокола,
показывая информацию управления в
соответствующих уровнях модели OSI.
Анализатор протокола - очень ценный
инструмент, но требует неплохого знания
сетевых протоколов.
Вы также должны знать, что термин "сетевой
анализатор" может означать различные
вещи у разных продавцов. Некоторые продавцы
могут полагать, что сетевой монитор будет
называться сетевым анализатором. Мониторы
фиксируют информацию о трафике, типа
количество переданных фреймов в секунду
или число фреймов, которые содержат ошибки.
Эти устройства не являются истинными
анализаторами, так как они неспособны
декодировать информацию протокола более
высокого уровня, которую содержит
переданный фрейм.
Для уровней от канального до прикладного:
Performance Reporter
Ранее было невозможно получить сводное
представление обо всех системах и сетевой
эффективности в сложной и распределенной
среде. IBM SystemView for AIX Performance Reporter (Performance Reporter)
устраняет эту проблему обеспечивая
эффективные, информативные отчеты
основанные на данных, сгенерированных из
встроенной базы данных. Этот инструмент
позволяет часто обнаруживать возможные
проблемы до их возникновения.
Данные, собранные Performance Reporter помогут вам
узнать то, какие пользователи используют
какие ресурсы и проанализировать узкие
места и другие проблемы производительности.
Вы можете собрать информацию о
производительности с узлов под управлением
AIX, Sun Solaris, и HP-UX. Вы можете легко
использовать данные из базы данных Performance
Reporter в других прикладных программах. Модель
данных хорошо зарегистрирована и просто
изменяется.
Performance Reporter поддерживает СУБД DB2/6000 и Oracle.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Безопасность
Система безопасности 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