Где в системе solaris располагаются файлы загрузки
Полный цикл загрузки Solaris (версия Unix System V Release 4, поставляющаяся фирмой Sun) на компьютерах х86 происходит в шесть этапов. Первые три этапа стандартны для всех ОС, работающих на IBM PC-совместимой технике. При включении компьютера запускается прошитый в ПЗУ BIOS. Он проводит тестирование процессора и памяти и инициализацию машины. В процессе инициализации BIOS устанавливает обработчик прерывания int 13h. Этот обработчик умеет считывать и записывать отдельные секторы жестких и гибких дисков и производить некоторые другие операции над дисковыми устройствами. Первичные загрузчики ОС обычно пользуются этим сервисом. Некоторые ОС, например MS/DR DOS, используют этот сервис не только при загрузке, но и при работе, и, благодаря этому, могут не иметь собственного модуля управления дисками.
Если загрузка происходит с жесткого диска, BIOS загружает в память и запускает нулевой сектор нулевой дорожки диска. Этот сектор обычно содержит не первичный загрузчик операционной системы, a MBR (Master Boot Record — главная загрузочная запись). Эта программа обеспечивает разбиение физического жесткого диска на несколько логических разделов (partition) и возможность попеременной загрузки различных ОС, установленных в этих разделах .
MBR перехватывает прерывание int 13h и транслирует обращения к дисковой подсистеме так, что обращения к логическому диску N преобразуются в обращения к N-ному разделу физического диска. Один из разделов диска должен быть помечен как активный или загрузочный. MBR загружает начальный сектор этого раздела — обычно это и есть первичный загрузчик ОС. Многие реализации MBR, в том числе и поставляемая с Solaris, могут предоставлять пользователю выбор раздела, с которого следует начинать загрузку. Выбор обычно предоставляется в форме паузы, в течение которой пользователь может нажать какую-то клавишу или комбинацию клавиш. Если ничего не будет нажато, начнется загрузка с текущего активного раздела.
Так или иначе, но загрузочный сектор — по совместительству, первичный загрузчик Solaris оказывается в памяти и начинает исполняться. Исполнение его состоит в том, что он загружает — нет, еще не ядро, а специальную программу, называемую DCU (Device Configuration Utility, утилита конфигурации устройств). Основное назначение этой программы — имитация сервисов консольного монитора компьютеров фирмы Sun на основе процессоров SPARC. DCU производит идентификацию установленного в машине оборудования. Пользователь может вмешаться в этот процесс и, например, указать системе, что такого-то устройства в конфигурации нет, даже если физически оно и присутствует, или установить драйверы для нового типа устройств. Драйверы, используемые DCU, отличаются от драйверов, используемых самим Solaris, называются они BEF (Boot Executable File), и начинают исполнение, как и сама DCU, в реальном режиме процессора х86. Найдя все необходимое оборудование, DCU запускает вторичный загрузчик Solaris. Логический диск, выделенный Solaris, имеет внутреннюю структуру и также разбит на несколько разделов. Чтобы не путать эти разделы разделами, создаваемыми MBR, их называют слайсами (slice). Загрузочный диск Solaris должен иметь минимум два байта— Root (корневая файловая система) и Boot, в котором и размещаются вторичный загрузчик и DCU. Вторичный загрузчик, пользуясь BEF-модулем загрузочного диска для доступа к этому диску, считывает таблицу слайсов и находит корневую файловую систему. В этой файловой системе он выбирает файл /kernel/unix, который и является ядром Solaris. В действительности, вторичный загрузчик исполняет командный файл, в котором могут присутствовать условные операторы, и, зависимости от тех или иных условий, в качестве ядра могут быть использованы различные файлы, /kernel/unix используется по умолчанию. Кроме того, пользователю предоставляется пауза (по умолчанию 5 секунд), в течение которой он может прервать загрузку по умолчанию и приказать загрузить какой-то другой файл, или тот же файл, но с другими параметрами. Будучи так или иначе загружено, ядро, пользуясь сервисами вторичного загрузчика, считывает файл /etc/system, в котором указаны параметры настройки сие темы. Затем, пользуясь информацией, предоставленной DCU, ядро формирует дерево устройств— список установленного в системе оборудования, и в соответствии с этим списком начинает подгружать модули, управляющие устройствами — драйверы. Подгрузка по-прежнему происходит посредством сервисов вторичного загрузчика — ведь все драйверы размещены на загрузочном диске и в корневой файловой системе, в том числе и драйверы самого этого диска 1 этой файловой системы.
Загрузив драйверы всех дисковых устройств и файловых систем (а при загрузке из сети — также сетевых контроллеров и сетевых протоколов), ядро начинает их инициализацию. С этого момента использовать сервисы вторичного загрузчика становится невозможно, но они уже и не нужны. Проинициализировав собственный драйвер загрузочного диска и корневой файловой системы, ядро запускает программу init, которая подключает остальные диски и файловые системы, если они есть, указывает параметры сетевых устройств и инициализирует их, запускает обязательные сервисы, в общем, производит всю остальную стартовую настройку системы.
Существуют ОС, которые не умеют самостоятельно выполнять весь цикл бутстрапа. Они используют более примитивную операционную систему, которая исполняет их вторичный (или какой это уже будет по счету) загрузчик, и помогает этому загрузчику поместить в память ядро ОС. На процессорах х86 в качестве стартовой системы часто используется MS/DR DOS, а загрузчик новой ОС оформляется в виде ЕХЕ-файла.
Таким образом устроены системы MS Windows 1.x—3.x, Windows 95/98/МЕ, DesqView и ряд других "многозадачников" для MS DOS. Таким же образом загружается сервер Nowell Netware, система Oberon для х86, программы, написанные для различных расширителей DOS (DOS extenders) и т. д. Многие из перечисленных систем, например Windows (версии младше 3.11 - в обязательном порядке, а 3.11 и 95/98/МЕ только в определенных конфигурациях) используют DOS и во время работы в качестве дисковой подсистемы. Тем не менее, эти программные пакеты умеют самостоятельно загружать Пользовательские программы и выполнять все перечисленные во введении Функции и должны, в соответствии с нашим определением, считаться полноценными операционными системами.
Аннотация: В лекции рассмотрены вопросы безопасности в ОС Unix, настройка данной ОС, управление пользователями и системой, поиск вторжений в данную ОС.
На протяжении большей части истории интернета системы Unix обеспечивали наивысший уровень функционирования служб в сети. Когда хакеры стали серьезной проблемой для всемирной сети, системам Unix начали уделять все больше внимания. На сегодняшний день большая часть систем в интернете работает под управлением ОС Unix, и для надежной защиты от хакеров эти системы должны быть правильно настроены.
В данной лекции приводятся некоторые базовые соображения безопасности, связанные с построением и защитой системы Unix. Ввиду большого числа доступных на рынке Unix-систем точные местоположения файлов и команды не являются абсолютно правильными для всех версий Unix. Где это представляется возможным, автор указывает корректировочную информацию для систем Sun Solaris и Linux.
Настройка системы
После построения системы Unix в ней, как правило, присутствует ряд уязвимостей. Большую их часть можно устранить посредством обновления системы или внесения изменений в конфигурационные файлы. В следующих разделах выделяются наиболее распространенные проблемы безопасности и способы их устранения.
Файлы загрузки
Системы Unix настраиваются при загрузке с использованием соответствующих загрузочных файлов. В зависимости от версии Unix файлы загрузки могут располагаться в различных местах. В системе Solaris файлы загрузки находятся в каталоге /etc/ rc2 .d , в системе Linux - в каталоге /etc/rc.d/ rc2 .d . В различных версиях Unix файлы могут располагаться в различных местах, это расположение действительно для Red Hat .
В файлах загрузки запускается ряд служб. Некоторые из них ( сеть , монтировка файловых систем и журнал запуска) необходимы для функционирования системы, и ничто не должно препятствовать их работе. Другие службы не являются столь критичными и запускаются в зависимости от того, каким образом используется система. Чтобы предотвратить запуск службы, просто измените имя файла . Убедитесь, что новое имя файла не начинается с буквы S или K. Рекомендуется размещать в качестве первого символа точку (<.>) в имени файла (это скрывает файл от просмотра, поэтому его нельзя будет перепутать с функционирующим файлом). Если служба не понадобится в будущем, файл можно удалить.
Службы, обычно запускаемые при помощи файлов загрузки, включают в себя следующие сервисы:
- Inetd;
- NFS;
- NTP ;
- Routed;
- RPC;
- Sendmail;
- Web servers.
Необходимо обязательно просмотреть файлы загрузки и определить, не запускаются ли необязательные службы (в следующем разделе рассказывается о том, как выявлять необязательные службы).
Начните с перечня служб, необходимых для предполагаемого использования системы. После выявления этого перечня отключите все остальные службы.
Службы, работу которых следует разрешить
Набор служб, выбранных для систем Unix, зависит от того, каким образом они будут использоваться. Некоторые из этих служб будут запускаться с помощью файлов загрузки; ряд служб контролируется через сервис inetd и настраивается в файле /etc/inetd.conf . Приведенный ниже текст представляет собой часть файла inetd.conf системы Solaris. Строки, начинающиеся с символа решетки - комментарии.
Файл inetd.conf не только контролирует службы типа FTP и telnet, но и некоторые службы RPC . Файл inetd.conf необходимо очень внимательно проверять на предмет того, что в нем сконфигурированы только необходимые службы. После правильной настройки файла необходимо перезапустить службу inetd посредством следующей команды:
Команда -HUP вызывает повторное считывание службой inetd ее конфигурационного файла.
Многие службы, настраиваемые по умолчанию на системах Unix, необходимо отключить. Ниже приведен перечень этих служб.
Кроме того, можно отключить службы Daytime, Time и SNMPD, если они не используются. Служба Time может использоваться некоторыми системами синхронизации, а служба SNMPD - для управления системой.
Как видно из приведенного выше фрагмента содержимого файла inetd.conf, службы telnet и FTP , как правило, настроены на рабочее состояние. Эти два протокола позволяют передавать идентификаторы пользователей и пароли через сеть в открытом виде. Возможно использование шифрующих версий этих протоколов для защиты паролей. При работе через telnet рекомендуется использовать Secure Shell ( SSH ). Некоторые версии SSH входят в программу Secure Copy ( SCP ) для передачи файлов.
Сетевая файловая система
Внутри организации может потребоваться использование файловой системы Network File System ( NFS ). Если это не так, отключите NFS на любой системе, на которой не требуется ее использование. NFS предназначена для монтирования файловой системы с одной системы на другую. Если NFS настроена неправильно, то велика вероятность того, что кто-то получит доступ к секретным файлам. Чтобы правильно настроить NFS , следует соответствующим образом изменить файл /etc/ dfs /dfstab .
Примечание
Неблагоразумно разрешать экспорт файловых систем во внешнюю среду из рассматриваемой организации.
Аннотация: Лекция посвящена файловой системе Solaris. В ней рассказывается как о классических принципах файловых систем UNIX, воплощенных в Solaris, так и о более новых расширениях, таких как списки управления доступом. Рассматриваются все управляющие структуры файловых систем, рассказывается о создании и монтировании файловых систем.
Файлы устройств Solaris
Каждому физическому устройству в Solaris обязательно соответствует файл устройства . Файл устройства по сути - это указатель на область кода ядра, в которой находится драйвер устройства. Файлы устройств располагаются в каталоге /dev и его подкаталогах. Такое расположение является стандартным для всех систем UNIX . Однако на самом деле в Solaris все файлы в каталоге /dev являются символическими ссылками на "настоящие" файлы устройств , которые располагаются в подкаталогах каталога /devices. Там эти файлы сгруппированы по отношению к своему месту в конфигурации компьютера. Подробнее это рассматривается ниже в разделе "Каталог /devices". О символических ссылках говорится также в лекции 5 раздела "Ссылки".
Файлы устройств имеют специальные типы: файл символьного устройства и файл блочного устройства .
Вывод программы ls иллюстрирует это:
Файл устройства является псевдофайлом, он не размещен на диске, о нем есть только запись , которая используется при доступе к устройству. Первое число, которое стоит в поле длины файла в выводе программы ls для файлов устройств , - это major-номер, а второе, после запятой - minor-номер. Первый из них означает номер типа устройств и одновременно - позицию в ядре, в которой следует искать драйвер устройства. Второй - номер экземпляра устройства данного типа. Поэтому файлы однотипных устройств в вышеприведенном выводе ls имеют одинаковые major-номера.
Устройство каждого типа имеет свой major-номер. Major-номера назначаются автоматически программой add_drv . Соответствие имени драйвера и major-номера определяется в файле /etc/name_to_major.
В Solaris каждое устройство имеет три разных имени: логическое имя, физическое имя и экземплярное имя.
Логические имена - это имена файлов устройств , которые хранятся в /dev.
Физические имена - это имена файлов устройств , хранящихся в /devices.
Экземплярные имена - это укороченные физические имена устройств, которые ядро назначает устройствам.
Ниже рассмотрен пример назначения всех перечисленных типов имен.
Файлы разделов дисков в Solaris
Мы предполагаем, что читатель знаком с физическим устройством жестких дисков, поэтому здесь не объясняются термины "головка", "дорожка", "цилиндр", "сектор" и другие. Все они являются общими для описания любых жестких дисков в любых компьютерах, независимо от архитектуры или используемой операционной системы.
Жесткий диск принято делить на разделы (в Solaris их называют slices). Раздел - это группа расположенных рядом цилиндров. Смысл разделения диска на разделы состоит в том, чтобы:
- минимизировать расстояние, которое потребуется головке диска для считывания фрагментов одного файла ;
- разделить данные разных типов, чтобы обезопасить системные данные от возможной порчи пользовательскими программами;
- зарезервировать под системные нужды достаточное пространство на диске так, чтобы несистемные файлы не могли его занять.
В Solaris на одном физическом жестком диске может быть до восьми разделов , которые принято нумеровать цифрами от 0 до 7.
Каждому разделу соответствует свой файл устройства в каталоге /dev/dsk. Пространство под разделы выделяется цилиндрами. Раздел однозначно определяется номерами начального и конечного цилиндров. В Solaris принята следующая концепция именования таких файлов устройств : в имени устройства учитываются номер контроллера, SCSI ID ( target number), номер диска ( LUN - Logical Unit Number) и номер раздела на диске (см. рис. 5.1). Если это диск IDE , то роль SCSI ID играет пара master/ slave (соответственно, 0/1). Для встроенных дисков SCSI и любых дисков IDE номер диска равен 0. Это иллюстрирует рис. 5.2.
Так, для системы с дисками SCSI /dev/dsk/c0t0d0s0 будет указывать на нулевой контроллер SCSI (c0), диск со SCSI ID 0 (t0), диск номер 0 на этом SCSI контроллере (d0), нулевой раздел на этом диске (s0).
Как показано на рис. 5.2, при создании файла устройства для раздела , который находится на IDE -диске, в названии файла учитываются номер адаптера IDE (как правило, в компьютерах x86 используют системные платы с одним адаптером, который поддерживает два канала IDE ), номер канала (он кодируется как SCSI ID , как показано в табл. 5.1), номер диска (всегда d0) и номер раздела (первый раздел на диске - s0 и т.д., подобно разделам на SCSI -дисках).
Сказанное выше об именовании файлов устройств дисков IDE относится к системам на платформе SPARC . На платформе х86 файлы устройств , соответствующие разделам дисков IDE , именуются несколько иначе. Файлы , соответствующие разделам fdisk, обозначаются cNdMpK, где после с идет номер контроллера, после d - номер диска, а после p - номер раздела fdisk. На каждом из разделов fdisk может быть создано несколько подразделов (slices), если этот раздел fdisk является разделом типа Solaris. Любой раздел fdisk имеет свой тип, он указывается в таблице Master Boot Record ( MBR ), в которой описаны все разделы fdisk-диска .
По умолчанию при установке Solaris на IDE - диск на платформе IA ( x86 ) программа -установщик создает два раздела fdisk - загрузочный (примерно 20 Мб) с программой-загрузчиком и раздел , на котором будут находиться все остальные части системы, а также пользовательские файлы . Первый раздел fdisk имеет тип FAT , а второй - тип Solaris. На втором разделе создаются подразделы (slices). Они именуются по такому же принципу, как и разделы на дисках систем SPARC , но без указания SCSI ID : c0d0s0, c0d0s1 и т.д.
Каждому файлу из каталога /dev/dsk соответствует файл устройства прямого доступа ( raw disk ) в каталоге /dev/rdsk:
В Solaris принято, что раздел номер 2 ( slice 2) представляет собой весь диск , т.е. является репрезентацией всего диска в целом, со всеми его разделами . Иначе говоря, на диске на самом деле может быть создано до 7 разделов , а восьмой ( раздел 2) всегда охватывает все эти разделы вместе. Поэтому в разделе 2 нельзя создать файловую систему и записывать туда файлы : он служит для системных надобностей. В частности, в структурах, адресуемых через раздел 2, хранятся сведения о диске в целом: реальный размер, число цилиндров и т.п.
Замечание о разных типах имен устройств можно проиллюстрировать на примере именования разделов диска . Так, разделам SCSI-диска со SCSI ID , равным 6, присоединенным к нулевому контроллеру, будут соответствовать логические имена устройств ( разделов диска ) от /dev/dsk/c0t6d0s0 до /dev/dsk/c0t6d0s7, физические имена от /devices/pci@1f,0/pci@1,1/ scsi @6/sd@0,0:a до /devices/pci@1f,0/pci@1,1/ scsi @6/sd@0,0:g. При этом диску в целом будет соответствовать экземплярное имя sd6.
Каждому физическому устройству в Solaris обязательно соответствует файл устройства . Файл устройства по сути – это указатель на область кода ядра , в которой находится драйвер устройства . Файлы устройств располагаются в каталоге /dev и его подкаталогах . Такое расположение является стандартным для всех систем UNIX . Однако на самом деле в Solaris все файлы в каталоге /dev являются символьными ссылками на "настоящие" файлы устройств, которые располагаются в подкаталогах каталога / devices . Там эти файлы сгруппированы по отношению к своему месту в конфигурации компьютера. Подробнее это рассмотрено ниже в разделе "каталог / devices ". О символьных ссылках подробнее рассказано в "Устройство и администрирование файловой системы UFS" в разделе "ссылки".
Файлы устройств имеют специальные типы:
- файл символьного устройства ;
- файл блочного устройства .
Вывод программы ls иллюстрирует это:
Файл устройства является псевдофайлом, он не размещен на диске, о нем есть только запись , которая используется при доступе к устройству. Первое число, которое стоит в поле длины файла в выводе программы ls для файлов устройств – это major номер, а второе, после запятой – minor номер. Первый из них означает номер типа устройств и одновременно – позицию в ядре , в которой следует искать драйвер устройства . Второй – номер экземпляра устройства данного типа. Поэтому файлы однотипных устройств в вышеприведенном выводе ls имеют одинаковые major номера.
Устройство каждого типа имеет свой major номер. Major номера назначаются автоматически программой add_drv . Соответствие имени драйвера и major номера определяется в файле /etc/name_to_major .
В Solaris все устройства имеют три имени разных типов: логическое имя, физическое имя и экземплярное имя.
Логические имена – это имена файлов устройств , которые хранятся в /dev .
Физические имена – это имена файлов устройств , хранящихся в / devices .
Экземплярные имена – это укороченные физические имена устройств, которые ядро назначает устройствам.
Ниже рассмотрен пример назначения всех перечисленных типов имен.
Файлы устройств для разделов дисков в Solaris
Мы предполагаем, что читатель знаком с физическим устройством жестких дисков , поэтому здесь не объясняются термины "головка", "дорожка", "цилиндр", "сектор" и другие. Все они являются общими для описания любых жестких дисков в любых компьютерах, независимо от архитектуры или используемой операционной системы.
Жесткий диск принято делить на разделы (в Solaris их называют slices ). Раздел – это группа расположенных рядом цилиндров. Смысл разделения диска на разделы состоит в том, чтобы:
- минимизировать расстояние , которое потребуется головке диска для считывания фрагментов одного файла;
- разделить данные разных типов, чтобы обезопасить системные данные от возможной порчи пользовательскими программами;
- зарезервировать под системные нужды достаточное пространство на диске так, чтобы несистемные файлы не могли его занять.
Жесткие диски
В Solaris на одном физическом жестком диске может быть до восьми разделов, которые принято нумеровать цифрами от 0 до 7.
Каждому разделу соответствует свой файл устройства в каталоге /dev/dsk. Пространство под разделы выделяется цилиндрами. Раздел однозначно определяется номерами начального и конечного цилиндров. В Solaris принята следующая концепция именования таких файлов устройств: в имени устройства учитываются номер контроллера , SCSI ID ( target number ), номер диска ( LUN – logical unit number ) и номер раздела на диске. Если это диск IDE , то роль SCSI ID играет пара master / slave (соответственно, 0/1). Для встроенных дисков SCSI и любых дисков IDE номер диска равен 0. Это иллюстрирует рис. 6.1.
Так, для системы с дисками SCSI /dev/dsk/c0t0d0s0 будет указывать на нулевой контроллер SCSI (c0), диск со SCSI ID 0 (t0), диск номер 0 на этом SCSI контроллере (d0), нулевой раздел на этом диске (s0).
Как показано на рис. 6.2, при создании файла устройства для раздела, который находится на IDE -диске, в названии файла учитываются номер адаптера IDE (как правило, в компьютерах x86 используют системные платы с одним адаптером , который поддерживает два канала IDE ), номер канала (он кодируется как SCSI ID, как показано в табл. 6.1), номер диска (всегда d0) и номер раздела (первый раздел на диске – s0 и т.д., подобно разделам на SCSI дисках).
Сказанное выше о, именовании файлов устройств дисков IDE относится к системам на платформе SPARC . На платформе х86 файлы устройств, соответствующие разделам дисков IDE , именуются несколько иначе. Файлы, соответствующие разделам fdisk, обозначаются cNdMpK, где после с идет номер контроллера , после d – номер диска, а после p – номер раздела fdisk. На каждом из разделов fdisk может быть создано несколько подразделов ( slices ), если этот раздел fdisk является разделом типа solaris . Любой раздел fdisk имеет свой тип, который указывается в таблице Master Boot Record ( MBR ), где описаны все разделы fdisk диска.
По умолчанию при установке Solaris на IDE -диск на платформе x86 программа-установщик Solaris создает два раздела fdisk – загрузочный (примерно 20 Мб) с программой- загрузчиком и раздел, на котором будут находиться все остальные части системы, а также пользовательские файлы. Первый раздел fdisk имеет тип FAT , а второй – тип Solaris . На втором разделе создаются подразделы ( slices ). Они именуются подобно таким же разделам на дисках систем SPARC , но без указания SCSI ID: c0d0s0, c0d0s1 и т.д.
Каждому файлу в каталоге /dev/dsk соответствует файл устройства прямого доступа ( raw disk ) в каталоге /dev/rdsk :
В Solaris принято, что раздел номер 2 ( slice 2) представляет собой весь диск, т.е. является репрезентацией всего диска в целом, со всеми его разделами. Иначе говоря, на диске на самом деле может быть создано до 7 разделов, а восьмой (раздел 2) всегда охватывает все эти разделы вместе. Поэтому на разделе 2 нельзя создать файловую систему и записывать туда файлы: он служит для системных надобностей. В частности, в структурах, адресуемых через раздел 2, хранятся сведения о диске в целом: реальный размер, число цилиндров и т.п.
Говоря о разных типах имен устройств, можно рассмотреть пример именования разделов диска . Так, разделам SCSI -диска со SCSI ID, равным 6, присоединенному к нулевому контроллеру , будут соответствовать логические имена устройств ( разделов диска ) от /dev/dsk/c0t6d0s0 до /dev/dsk/c0t6d0s7 , физические имена от / devices / pci @1f,0/ pci @1,1/ scsi @6/ sd @0,0:a до / devices / pci @1f,0/ pci @1,1/ scsi @6/ sd @0,0:g . При этом диску в целом будет соответствовать экземплярное имя sd6 .
Приводы для CD- и DVD-дисков
Для того, чтобы узнать, какие приводы есть в вашей системе и какие имена им назначены, можно воспользоваться prtconf или cdrecord (последняя программа может не входить в поставку Solaris , но она доступна в исходных кодах в Сети). В нижеследующем примере видно, что в компьютере установлен один привод, и если вставить в него диск, то можно увидеть, что автомонтирование диска произойдет для устройства /dev/dsk/c1t0d0s2 , что соответствует устройству с параметрами 1,0,0 из вывода cdrecord .
Каталог /devices
Каталог / devices отражает аппаратную конфигурацию компьютера. Дерево его подкаталогов строится в соответствии с реальными подключениями устройств к шинам и контроллерам . Поэтому для компьютеров различных архитектур структура дерева подкаталогов / devices будет разной. Содержание этих подкаталогов будет разным для разных компьютеров, даже если они имеют одинаковую архитектуру, потому что компьютеры могут иметь разную конфигурацию: неодинаковое количество жестких дисков , различные контроллеры интерфейсов ( SCSI , IDE ), по -разному подсоединенные к ним диски. Например, для компьютера x86 дерево может быть таким:
Это пример дерева подкаталогов каталога / devices Solaris , установленного на ноутбук IBM ThinkPad 390X.
Полный список всех устройств компьютера, с которыми система Solaris готова работать, содержится в файле /etc/path_to_inst .
Файл /etc/path_to_inst содержит соответствия физических имен устройств и номеров экземпляров устройств (тех, что называются minor номерами устройств). Чтобы эти соответсвия сохранялись от загрузки к загрузке, система записывает их в файл /etc/path_to_inst . Этот файл во время загрузки доступен только для чтения, он может быть изменен с помощью программ add_drv(1M) и drvconfig(1M) .
Обычно системному администратору незачем изменять этот файл . Для просмотра полного списка устройств следует применять команду prtconf :
Для просмотра списка устройств, фактически работающих в системе, используйте
Это позволяет отфильтровать в выводе prtconf строки, содержащие слово " not ", например, " device not attached ". Более подробно об изменении аппаратной конфигурации и добавлении драйверов устройств рассказывается в лекции 2 курса "Системное администрирование ОС Solaris 10".
Правильные ответы выделены зелёным цветом.
Все ответы: В курсе содержатся пошаговые инструкции по установке и использованию межсетевых экранов, сведения о безопасности беспроводных соединений и настольных компьютеров, о биометрических методах аутентификации и других современных способах защиты.
(1) устройство контроля доступа в сеть, предназначенное для блокировки всего трафика, за исключением разрешенных данных
(2) устройство функцией которого является доставка трафика в пункт назначения в максимально короткие сроки
(3) удаленные пользователи не ощущают себя изолированными от системы, к которой они осуществляют доступ
(3) механизмы шифрования могут и должны являться составной частью полнофункциональной программы по обеспечению безопасности
Данная политика определяет степень секретности информации внутри организации и необходимые требования к хранению, передаче, пометке и управлению этой информацией.
В каком файле должны быть определены файлы .cgi и .pl, чтобы программы выполнялись без отображения исходного кода на веб-странице?
(3) атака, запрещающая легальному пользователю использование системы, информации или возможностей компьютеров
В какой последовательности должны проходить процессы обеспечения информационной безопасности и управление риском?
(1) кто может осуществлять авторизованный доступ к тем или иным компьютерам организации, и какую информацию администраторы должны предоставлять пользователям, запрашивающим поддержку
(2) каким образом в данный момент времени применяется политика безопасности на различных системах, имеющихся в организации
Отличие анализаторов системных вызовов от анализаторов журналов и датчиков признаков заключается в том, что:
(3) атака, запрещающая легальному пользователю использование системы, информации или возможностей компьютеров
(1) самовоспроизводящихся компьютерных программ, которые распространяются, внедряя себя в исполняемый код других программ или в документы специального формата
Какие системы будут защищены межсетевым экраном, если почтовый сервер компании разместить между маршрутизатором и экраном?
(3) атака, запрещающая легальному пользователю использование системы, информации или возможностей компьютеров
Какую службу можно описать следующим образом: "обеспечивает секретность информации, открывает доступ к информации только аутентифицированным пользователям?"
Какие системы будут защищены межсетевым экраном, если почтовый сервер компании разместить за маршрутизатором и экраном?
(3) атака, запрещающая легальному пользователю использование системы, информации или возможностей компьютеров
Согласно закону HIPAA требования безопасности включают общие положения и детальные требования в следующих специфических областях:
(1) способ преобразования информации, применяемый для хранения важной информации в ненадежных источниках или передачи её по незащищённым каналам связи
(2) меры, принятые для предотвращения несанкционированного использования, злоупотребления, изменения сведений, фактов, данных или аппаратных средств либо отказа в доступе к ним
(3) механизм аутентификации, предполагающий использование определенного устройства для идентификации человеческих характеристик
(1) NIDS можно полностью скрыть в сети таким образом, что злоумышленник не будет знать о том, что за ним ведется наблюдение
(1) прослушивание (снифинг) работают только в сетях с разделяемой пропускной способностью с сетевыми концентраторами – хабами; использование коммутаторов обеспечивает достаточно надежную защиту от прослушивания
(2) прослушивание (снифинг) хорошо работают в сетях с разделяемой пропускной способностью с сетевыми концентраторами – хабами; использование коммутаторов снижает эффективность снифинга
(3) прослушивание (снифинг) работают только в сетях с коммутируемой средой, использующей коммутаторы; использование концентраторов исключает возможность снифинга
Какое из утверждений наиболее верно? На основании политики следующая информация считается принадлежащей организации:
Какой тип атаки был использован Кевином Митником для проникновения в Центр суперкомпьютеров в Сан-Диего?
(1) область Computer Configuration оснастки Local Security Policy; Область Computer Configuration оснастки Group Policies, связанной с сайтом; Область Computer Configuration оснастки Group Policies, связанной с доменом; Область Computer Configuration оснастки Group Policies, связанной с OU
(2) область Computer Configuration оснастки Local Security Policy; Область Computer Configuration оснастки Group Policies, связанной с сайтом; Область Computer Configuration оснастки Group Policies, связанной с сайтом; Область Computer Configuration оснастки Group Policies, связанной с OU
(3) область Computer Configuration оснастки Group Policies, связанной с сайтом; Область Computer Configuration оснастки Group Policies, связанной с сайтом; Область Computer Configuration оснастки Local Security Policy; Область Computer Configuration оснастки Group Policies, связанной с OU
Читайте также: