Конвертируем root в роль

Перед тем, как конвертировать пользователя root в роль, необходимо создать хотя бы одного обычного пользователя, которому будет назначена роль root. В противном случае можно совсем потерять доступ root к Solaris. Пользователь обязательно должен быть локальным, т.е. его учетные данные должны храниться в файлах, а не в LDAP или NIS. Пусть мы создали такого пользователя и назвали его manager.

Последовательность действий:

1. Заходим в систему под обычным пользователем. Если войти в систему пользователем root, перевести его в роль будет нельзя.

2. Становимся суперпользователем:

$ su - root
Password:
#

3. Конвертируем пользователя root в роль:

bash-3.00# usermod -K type=role root

4. Проверяем, что конвертация прошла успешно. В файле /etc/user_attr смотрим тип учетной записи root:

bash-3.00# grep root /etc/user_attr
root::::type=role;auths=solaris.*,solaris.grant;profiles=Web Console Management,All;lock_after_retries=no;clearance=admin_high;min_label=admin_low

5. Назначаем роль root пользователю:

bash-3.00# usermod -R root manager

Не  забудьте назначить роль root минимум одному пользователю! Иначе, потеряете доступ к root!

6. Заходим под обычным пользователем и активируем роль root:

$ id
uid=145(manager) gid=1(other)
$ su -
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
#

Пароль роли root такой же, как был у пользователя root.

Можно попробовать активировать роль root от имени пользователя, которому она не назначена:

$ id
uid=126(andrey) gid=1(other)
$ su -
Password:
Roles can only be assumed by authorized users
su: Sorry
$

Вот Вам и дополнительное преимущество: пользователь не может стать root, если ему не назначена соответствующая роль, даже если он знает пароль root.

Обратная конвертация root в пользователя

С обратной конвертацией все намного проще. Надо выполнить всего одну команду:

# rolemod -K type=normal root

Проверяем, что root снова обычный пользователь (type=normal в файле /etc/user_attr):

# grep root /etc/user_attr
root::::type=normal;auths=solaris.*,solaris.grant;profiles=Web Console Management,All;lock_after_retries=no;clearance=admin_high;min_label=admin_low

После этого root становиться отдельным пользователем, способным самостоятельно зайти в систему. Любой пользователь, знающий пароль root, может с успехом выполнить su – root.

Single user mode

В Single user mode для доступа к системе нужен пароль root. При этом не имеет значения, пользователем или ролью является root.

Когда Вы перевели root в роль, то единственным способом зайти в систему от имени root становиться single user mode. Так что если Вы ошиблись с распределением ролей и остались без root доступа к системе, в single user mode это можно исправить.

Похожие записи:

1. Понимаем RBAC
2. Создаем зеркало root диска на ZFS
3. Подключение Alfresco к MySQL в Solaris 10

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

Определяем, аудит чего будем вести

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

Все, что происходит в OpenSolaris связано с событиями, а события, аудит которых можно вести, сгруппированы в классы. Классы определены в файле: /etc/security/audit_class:

no:invalid class
fr:file read
fw:file write
fa:file attribute access
fm:file attribute modify
fc:file create
fd:file delete
cl:file close
nt:network
ip:ipc
na:non-attribute
lo:login or logout
ap:application
cy:cryptographic
ss:change system state
as:system-wide administration
ua:user administration
am:administrative (meta-class)
aa:audit utilization
ad:old administrative (meta-class)
ps:process start/stop
pm:process modify
pc:process (meta-class)
xp:X - privileged/administrative operations
xc:X - object create/destroy
xs:X - operations that always silently fail, if bad
xx:X - all X events (meta-class)
io:ioctl
ex:exec
ot:other
all:all classes (meta-class)

Например, если Вы хотите проводить аудит удаления файлов, то Вам надо надо настраивать аудит класса fd. Для нашего примера нужен класс lo для входа (login) и выхода (logout) из системы.

Актуальные системные события, которые входят в классы, задаются в файле /etc/security/audit_event, где более 500 уникальных системных событий. События могут входить в один или несколько классов. В класс lo входят следующие события:

6152:AUE_login:login - local:lo
6153:AUE_logout:logout:lo
6154:AUE_telnet:login - telnet:lo
6155:AUE_rlogin:login - rlogin:lo
6158:AUE_rshd:rsh access:lo
6159:AUE_su:su:lo
6162:AUE_rexecd:rexecd:lo
6163:AUE_passwd:passwd:lo
6164:AUE_rexd:rexd:lo
6165:AUE_ftpd:ftp access:lo
6171:AUE_ftpd_logout:ftp logout:lo
6172:AUE_ssh:login - ssh:lo
6173:AUE_role_login:role login:lo
6212:AUE_newgrp_login:newgrp login:lo
6213:AUE_admin_authenticate:admin login:lo
6221:AUE_screenlock:screenlock - lock:lo
6222:AUE_screenunlock:screenlock - unlock:lo
6227:AUE_zlogin:login - zlogin:lo
6228:AUE_su_logout:su logout:lo
6229:AUE_role_logout:role logout:lo
6244:AUE_smbd_session:smbd(1m) session setup:lo
6245:AUE_smbd_logoff:smbd(1m) session logoff:lo
9101:AUE_ClientConnect:client connection to x server:lo
9102:AUE_ClientDisconnect:client disconn. from x server:lo

Настраиваем аудит

Классы, аудит которых Вы хотите проводить, задаются в файле /etc/security/audit_control. Ниже содержимое этого файла по-умолчанию:

dir:/var/audit
flags:
minfree:20
naflags:lo

Каталог по-умолчанию для аудита /var/audit. Вы можете выбрать другой каталог, например, NFS-каталог подключенный с другого сервера. Классы, аудит которых мы хотим выполнять, задаются в поле flags, то есть нам нужно добавит lo в наш файл следующим образом:

dir:/var/audit
flags:lo
minfree:20
naflags:lo

Поле minfree задает минимальный процент свободного места в каталоге аудита. Если места осталось меньше, то будет вызван audit warning script, который, как правило, настроен на отправку email кому-либо. Как работать с audit warning script смотрите в man audit_warn(1M).

Поле naflags (non-attributable flags) для событий, которые не могут быть отнесены к какому-либо пользователю. Как правило, эти события связаны с программами, автоматически запускающимися во время загрузки.

Включение аудита

Включение аудита требует запуска /etc/security/bsmconv и перезагрузки машины.

bleonard@os200906:~$ pfexec /etc/security/bsmconv
This script is used to enable Solaris Auditing and device allocation.
Shall we continue with the conversion now? [y/n] y
bsmconv: INFO: checking startup file.
bsmconv: INFO: turning on audit module.
bsmconv: INFO: initializing device allocation.

Solaris Auditing and device allocation is ready.
If there were any errors, please fix them now.
Configure Solaris Auditing and device allocation by editing files
located in /etc/security.
Reboot this system now to come up with auditing and device allocation enabled.
bleonard@os200906:~$ pfexec reboot

После перезагрузки в /var/audit появится один файл:

bleonard@os200906:~$ ls /var/audit
20100621202538.not_terminated.os200906

Посмотреть файл можно с помощью утилиты praudit (сокращение от print audit trail file).

bleonard@os200906:~$ pfexec praudit /var/audit/20100621202538.not_terminated.os200906 > audit.txt
bleonard@os200906:~$ cat audit.txt
file,2010-06-21 16:25:38.984 -04:00,
header,44,2,system booted,na,2010-06-21 16:23:25.458 -04:00
text,booting kernel
header,69,2,login - local,,localhost,2010-06-21 16:27:25.183 -04:00
subject,bleonard,bleonard,staff,bleonard,staff,477,3112795690,0 0 localhost
return,success,0
header,69,2,login - local,,localhost,2010-06-21 16:28:24.881 -04:00
subject,bleonard,bleonard,staff,bleonard,staff,615,3530634311,0 0 localhost
return,success,

Однако, данные аудита могут быть извлечены в виде XML и затем конвертированы в HTML для лучшего форматирования:

bleonard@os200906:~$ pfexec praudit -x /var/audit/20100621202538.not_terminated.os200906 > audit.xml
bleonard@os200906:~$ xsltproc audit.xml > audit.html

Затем просто откройте файл в Firefox:

bleonard@os200906:~$ firefox audit.html &
[1] 1919

Вы можете видеть в этом коротком отрывке, что я зашел в OpenSolaris в 16:28 в понедельник, 21 июня.

Изменяем аудит

Если Вы решили, что хотите проводить аудит еще каких-то событий, то просто добавьте эти события в файл audit_control. Например, очень популярен аудит запускаемых команд. Запускаемые команды могут быть записаны с использованием класса ex:

dir:/var/audit
flags:lo,ex
minfree:20
naflags:lo

Файл audit_control читается, когда пользователь входит в систему. Если посмотреть на конфигурацию аудита в текущий момент, то увидим, что мы все еще отслеживаем только класс lo:

bleonard@os200906:~$ pfexec auditconfig -getaudit
audit id = bleonard(101)
process preselection mask = lo(0x1000,0x1000)
terminal id (maj,min,host) = 0,0,localhost(127.0.0.1)
audit session id = 3530634311

Однако, если мы зайдем по ssh на машину, то изменения в конфигурации аудита будут учтены:

bleonard@os200906:~$ ssh -X bleonard@os200906
The authenticity of host 'os200906 (127.0.0.1)' can't be established.
RSA key fingerprint is 6c:c7:63:7f:dc:1f:33:1e:94:ee:eb:24:23:de:8f:90.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'os200906' (RSA) to the list of known hosts.
Password:
Last login: Mon Jun 21 16:28:24 2010
Sun Microsystems Inc.   SunOS 5.11      snv_111b        November 2008
bleonard@os200906:~$ pfexec auditconfig -getaudit
audit id = bleonard(101)
process preselection mask = ex,lo(0x40001000,0x40001000)
terminal id (maj,min,host) = 12324,202240,localhost(127.0.0.1)
audit session id = 3339125594

Давайте теперь запустим команду, например zfs list -t all, и снова извлечем информацию аудита:

В третьей записи вы можете увидеть, что была запущена команда /sbin/zfs. Также интересно, как Вы можете видеть из первой записи, что была запущена команда /usr/sbin/auditconfig. Именно так изменения в конфигурации аудита обнаруживаются, когда мы входим в систему.

Политика аудита

В дополнение к событиям, выбранным для аудита, Вы можете настроить объем данных, собираемых для каждого события с помощью политики аудита. Политика может быть настроена динамически с помощью команды auditconfig, или статически в файле /etc/security/audit_startup. Одна из популярных политик аудита – установка параметра +argv, которая позволяет включать в аудит событий exec аргументы, которые передаются запускаемой команде.

Например, в записи аудита ZFS выше мы знаем, что пользователь bleonard запустил команду zfs, но с какими параметрами? Он создал моментальный снимок, клон, или экспортировал данные?

Включите запись аргументов exec():

bleonard@os200906:~$ pfexec auditconfig -setpolicy +argv

Чтобы изменения действовали после перезагрузки, нужно добавить команду, включающую политику +argv в файл audit_startup:

/usr/sbin/auditconfig -setpolicy +argv

Затем запустите команду zfs list -t all и заново генерируйте отчет аудита:

Здесь мы видим, что секция EXEC_ARGS сейчас является частью отчета аудита, и аргументы list, -t и all были переданы zfs.

Остановка аудита

Сервис аудит управляется SMF:

bleonard@os200906:~$ svcs -l auditd
fmri         svc:/system/auditd:default
name         Solaris audit daemon
enabled      true
state        online
next_state   none
state_time   Mon Jun 21 16:25:41 2010
logfile      /var/svc/log/system-auditd:default.log
restarter    svc:/system/svc/restarter:default
contract_id  73
dependency   require_all/none svc:/system/filesystem/local (online)
dependency   require_all/none svc:/milestone/name-services (online)
dependency   require_all/none svc:/system/system-log (online)

Чтобы остановить его, просто запустите:

bleonard@os200906:~$ svcadm disable auditd

Остановка сервиса аудита также останавливает журнал. Когда сервис будет запущен снова, будет создан новый файл журнала аудита.

Скрипт для аудита

Вот удобный скрипт для извлечения и конвертации в HTML записей аудита. После запуска Firefox, скрипт обновляет HTML каждые 10 секунд, и обновление в браузере будет показывать последние записи.

bleonard@os200906:~$ cat showauditlive
pfexec praudit -x /var/audit/*not_term* > audit.xml
xsltproc audit.xml > audit.html
firefox audit.html &
while [ true ]; do
        pfexec praudit -x /var/audit/*not_term* > audit.xml
        xsltproc audit.xml > audit.html
        sleep 10
done

Статья включает только основы того, что можно делать с помощью аудита. Детально с возможностью аудита можно ознакомиться в руководстве System Administration Guide: Security Services, секция Solaris Auditing.

Дополнения от solarisblog.ru:

1. Хотя статья написана про OpenSolaris, она также применима и к Solaris 10.

2. В комментариях к оригинальной статье написано, что bsmconv/unconv устарели и аудит включен по-умолчанию (http://arc.opensolaris.org/caselog/PSARC/2009/354/ и http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6192139). Я пробовал в OpenSolaris 2009.06 и Solaris 10 10/09 – bsmconv все еще нужен для запуска аудита. В официальной документации по Solaris 10 System Administration Guide: Security Services также применяется bsmconv. Возможно, в будущие релизы эти изменения уже войдут, но пока для включения аудита нужна перезагрузка системы.

Похожие записи:

1. Понимаем RBAC

Role Based Access Control (RBAC) – функциональность OpenSolaris (Прим. переводчика. И просто Solaris, начиная с версии Solaris 8), предоставляющая большие возможности. Однако, ее трудно понять из-за обилия раздельных компонентов, связанных между собой. В этой записи я попытаюсь написать, что понял я.

Сначала несколько определений:

Пользователь

Пользователь в системе. Основная информация об учетных записях пользователей определяется в /etc/passwd:

bleonard@opensolaris:~$ grep "bleonard" /etc/passwd
bleonard:x:101:10:Brian Leonard:/export/home/bleonard:/bin/bash

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

Дополнительная информация о пользователях для RBAC определяется в /etc/user_attr:

bleonard@opensolaris:~$ grep "bleonard" /etc/user_attr
bleonard::::profiles=Primary Administrator;roles=root

Для пользователя bleonard определен один профиль, Primary administrator, и одна роль, root.

Роль

Роль – это именованное множество полномочий, которые могут быть активированы. Роли, как и пользователи, определяются в файле /etc/passwd:

bleonard@opensolaris:~$ grep "root" /etc/passwd
root:x:0:0:Super-User:/root:/usr/bin/bash

Однако, по-умолчанию в OpenSolaris root определен как роль, а не как пользователь.

bleonard@opensolaris:~$ grep "root:" /etc/user_attr 
root::::type=role;auths=solaris.*,solaris.grant;profiles=All;lock_after_retries=no;min_label=admin_low;clearance=admin_high

Пользователь может активировать роль. Это похоже на надевание костюма. Однако, Вы на самом деле становитесь тем, что одеваете. Роль активируется командой su. Необходимо ввести пароль root, который Вы назначили при установке:

bleonard@opensolaris:~$ su root
Password:
bleonard@opensolaris:~#

Профиль

Профиль - это именованное множество полномочий, которые могут быть выполнены. По этой причине они еще называются выполняемые профили. Запуск производится с помощью команды pfexec, сокращение от «profile execution». Многие сравнивают pfexec с sudo, и они часто могут использоваться заменяя друг друга. Но когда Вы на самом деле поймете pfexec, Вы осознаете, насколько более мощной она может быть.

Команды, которые позволяет запускать данный профиль, определяются в файле /etc/security/exec_attr.

bleonard@opensolaris:~$ grep "Primary Administrator" /etc/security/exec_attr
Primary Administrator:suser:cmd:::*:uid=0;gid=0

Звездочка  »*» означает, что Primary Administrator может запускать любые команды, и они будут работать от имени пользователя root (uid=0).

Полномочия, связанные с профилем, задаются в файле /etc/security/prof_attr:

bleonard@opensolaris:~$ grep "Primary Administrator" /etc/security/prof_attr
Primary Administrator:::Can perform all administrative tasks:auths=solaris.*,solaris.grant;help=RtPriAdmin.html

Полномочия

Полномочия дают Вам привилегию на выполнение некоторой операции. Привилегия со звездочкой solaris.*  дает Primary Administrator право выполнять любую операцию. Полный список привилегий можно посмотреть в /etc/security/auth_attr.

RBAC в действии

Чтобы понять, как все это работает, давайте поэкспериментируем с ролями и профилями.

Действия с ролями

Давайте уберем роль root у пользователя bleonard:

bleonard@opensolaris:~$ pfexec usermod -R "" bleonard
UX: usermod: bleonard is currently logged in, some changes may not take effect until next login.
bleonard@opensolaris:~$ grep "bleonard" /etc/user_attr
bleonard::::type=normal;profiles=Primary Administrator

Теперь не получится активировать роль root:

bleonard@opensolaris:~$ su root
Password:
Roles can only be assumed by authorized users
su: Sorry

Но так как bleonard все еще Primary Administrator, он может получить привилегии root используя pfexec:

bleonard@opensolaris:~$ pfexec su root
bleonard@opensolaris:~#

Возвращаем роль root обратно:

bleonard@opensolaris:~# usermod -R root bleonard
UX: usermod: bleonard is currently logged in, some changes may not take effect until next login.

Действия с профилями

Давайте удалим профиль Primary Administrator у пользователя bleonard (если Вы пытаетесь сделать это на своей системе, убедитесь, что Вы вернули роль root, иначе можете совсем потерять доступ root).

bleonard@opensolaris:~$ pfexec usermod -P "" bleonard 
UX: usermod: bleonard is currently logged in, some changes may not take effect until next login.

Теперь давайте попробуем вернуть профиль:

bleonard@opensolaris:~$ pfexec usermod -P "Primary Administrator" bleonard
UX: usermod: ERROR: Permission denied.

К счастью, Вы все еще можете активировать роль root:

bleonard@opensolaris:~$ su
Password:
bleonard@opensolaris:~# usermod -P "Primary Administrator" bleonard
UX: usermod: bleonard is currently logged in, some changes may not take effect until next login.

Простой пользовательский интерфейс

Наконец, есть простой пользовательский интерфейс для управления пользователями и ролями. Вы найдете его в System > Administration > Users and Groups:

Дополнительные материалы:

• RBAC and Privileges – Parts 1 – 4.
• Introducing pfexec, a Convenient Utility in the OpenSolaris OS

Похожие записи:

1. Конвертируем пользователя root в роль
2. Аудит

Прежде чем начать, я бы хотел направить всех к посту Scott Rotondo, одного из архитекторов проекта Secure by Default (SBD). Просмотрите пост и напишите автору, что вы думаете об этом новом расширении Solaris.

Сегодня SBD предлагается в виде «все или ничего» – он либо включен, любо выключен с помощью новой команды netservices(1M). Для многих организаций этого недостаточно. Часто требуется сконфигурировать систему так, чтобы некоторые сервисы были выключены или переведены в режим «local only», а другие включены или «открыты» для поддержки бизнес- или технических требований. Поэтому важно понимать, что именно делает SBD, чтобы Вы лучше могли настроить конфигурацию безопасности своей системы основываясь на своих специфических требованиях. Как я уже писал ранее, конфигурация SBD создается (1) выключением сервисов или (2) настройкой свойств сервисов так, чтобы сервис работал в режиме «local only».

Включение и выключение сервисов – тривиальная задача. Просто используйте команду svcadm с параметрами enable или disable для настройки интересующего Вас сервиса. Так как это простая задача, не будем ее рассматривать подробно. В третьей и последней части Узнаем: Solaris Secure by Default, я бы хотел сосредоточится на тех сервисах, которые не выключены по-умолчанию, а вместо этого настроены так, чтобы принимать только локальные запросы (создаваемые самой системой).

Посмотрите проектный документ Secure By Default, и вы увидите список таких сервисов (представленный с использованием FMRI):

• svc:/network/rpc/bind
• svc:/system/system-log
• svc:/network/smtp:sendmail
• svc:/system/webconsole:console
• svc:/application/management/wbem
• svc:/application/x11/x11-server
• svc:/application/graphical-login/cde-login
• svc:/network/rpc/cde-ttdbserver:tcp
• svc:/network/rpc/cde-calendar-manager
• svc:/application/print/rfc1179:default

Чтобы задать, работает сервис в обычном режиме, или в Secure by Default, используются свойства SMF. В таблице ниже значения свойств, установленные, когда сервис работает в режиме SBD, выделены жирным шрифтом.

Очень просто, правда? Итак, представим, что Вы работаете в режиме SBD (после запуска команды netservices limited), и у Вас появилась необходимость получать сообщения syslog с других хостов. Все, что Вам нужно сделать:

# svccfg -s system-log setprop config/log_from_remote = true
# svcadm refresh system-log

Если Вы хотите, чтобы изменения вступили в силу немедленно, нужно дополнительно запустить:

# svcadm restart system-log

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

# ifconfig hme0
hme0: flags=1000843 mtu 1500 index 2
        inet 192.168.1.250 netmask ffffff00 broadcast 192.168.1.255
        ether 0:0:0:0:0:0

# rpcinfo -p 192.168.1.250
   program vers proto   port  service
    100000    4   tcp    111  rpcbind
    100000    3   tcp    111  rpcbind
    100000    2   tcp    111  rpcbind
    100000    4   udp    111  rpcbind
    100000    3   udp    111  rpcbind
    100000    2   udp    111  rpcbind

# zlogin time ifconfig hme0:2
hme0:2: flags=1000843 mtu 1500 index 2
        inet 192.168.1.240 netmask ffffff00 broadcast 192.168.1.255

# zlogin time rpcinfo -p 192.168.1.250
rpcinfo: can't contact portmapper: RPC: Authentication error; why = Failed (unspecified error)

Замечательно! На этом третий выпуск  заканчивается. Пожалуйста, сообщите мне, что Вы думаете, или если ли у Вас есть какие-то вопросы. Мне нравится получать отклики и ваше мнение очень важно для нас.

До скорого, Глен.

Другие части статьи: часть 1, часть 2.

Похожие записи:

1. Безопасность по умолчанию в Solaris, часть 1
2. Безопасность по умолчанию в Solaris, часть 2
3. Подключение Alfresco к MySQL в Solaris 10

Во втором выпуске «Узнаем: Solaris Secure by Default (SBD)» я бы хотел обратить ваше внимание на страницу проекта Secure by Default OpenSolaris. В особенности убедитесь, что изучили проектный документ.

Этот документ имеет большое значение для понимания того, что именно было сделано в рамках проекта SBD в процессе интеграции в Nevada билд 42. Документ предоставляет удобный справочник по изменениям, которые были внесены SBD, включая введение новых FMRI сервисов, статусы сервисов (enabled или disabled), а также свойства, которые были использованы для управления работой сервисов.

Итак, пожалуйста, посмотрите и дайте знать, что вы думаете.

До скорого, Glenn.

Похожие записи:

1. Безопасность по умолчанию в Solaris, часть 1
2. Безопасность по умолчанию в Solaris, часть 3
3. Top 5 средств безопасности Solaris 10, которые следует использовать

Предыдущие версии Solaris 10 Security Deep Dive были закружены почти 8000 раз.

Похожие записи:

1. Top 5 средств безопасности Solaris 10, которые следует использовать
2. Безопасность по умолчанию в Solaris, часть 1
3. Solaris Internals

Добро пожаловать в первый выпуск – Узнаем: Solaris Secure by Default (SBD)

Проект безопасность по умолчанию в Solaris (Solaris Secure by Default, или проще SBD) появился в build 42 Nevada. Он запланирован к включению в обновление Solaris очень скоро (Прим. перев. SBD включена в Solaris 10 11/06). Цель проекта SBD – уменьшить количество целей для сетевых атак на Solaris путем (1) отключения тех сервисов, которые не являются абсолютно необходимыми по умолчанию и (2) настройки остальных сервисов так, чтобы они принимали запросы только с локальной системы. Единственным исключением из этого правила является Secure Shell, который запущен и работает. Это очень похоже на сетевую конфигурацию, обычно генерируемую Solaris Security Toolkit, но значительным отличием является то, что SBD встроен в Solaris.

SBD уже реализована для ON, X11, CDE и Admin/Install. Продолжается работа над обеспечением JDS/Gnome поддержки SBD. До настоящего времени, однако, SBD выглядит чертовски здорово!
Давайте посмотрим на пример. Ниже вывод netstat с недавно установленной Ultra 10:

# netstat -f inet -P tcp -a

TCP: IPv4
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q    State
-------------------- -------------------- ----- ------ ----- ------ -----------
      *.*                  *.*                0      0 49152      0 IDLE
      *.sunrpc             *.*                0      0 49152      0 LISTEN
      *.*                  *.*                0      0 49152      0 IDLE
      *.ssh                *.*                0      0 49152      0 LISTEN
localhost.smtp             *.*                0      0 49152      0 LISTEN
localhost.submission       *.*                0      0 49152      0 LISTEN

Обратите внимание, что эта система не имеет монитора, и поэтому не запущен никакой менеджер окон. Как видите, остались запущенными только ssh, rpcbind и sendmail. Очевидно, что sendmail может принимать запросы только с localhost. Кажется, что rpcbind может принимать запросы по сети, но на самом деле это не так.
Большой побочный эффект SBD в том, что теперь меньше сетевых сервисов запускаются с помощью скриптов автозапуска, т.к. многие сервисы были переведены на использование SMF. Некоторые сервисы по умолчанию выключены с помощью SMF, а другие поддерживают свойства SMF для определения работать в режиме «local only» или нет. В примере выше prcbind управляется именно с помощь свойства SMF «local only».
В Nevada SBD будет использоваться по умолчанию при установке Solaris – вопросов задаваться не будет. В Solaris 10 будет предложен выбор, но SBD будет вариантом по умолчанию. SBD никак не влияет на обновляемые системы. Только новые установки позволят использовать преимущества SBD без настроек.
Вы можете включить SBD или вернуться обратно к традиционным настройкам Solaris в любое время после установки с помощью команды netservices. Находящаяся в каталоге /usr/sbin эта команда предоставляет возможность за одно действие переключить сетевые сервисы из традиционного (открытого) состояния в SBD и обратно:

# /usr/sbin/netservices
netservices: usage: netservices [ open | limited ]

Как Вы видите, команда netservices предоставляет две опции. Опция open изменит состояние и свойства сервисов для перевода системы в традиционное состояние. Опция limited переведет систему в состояние SBD. Обратите внимание, что эти команды подобны молотку, который принудительно перемещает вашу систему между двумя состояниями. Если Вы изменяли настройки сервисов (например, запускали или останавливали некоторые сервисы), то можете заметить, что Ваши настройки поменялись.
СОВЕТ: лучше использовать команду netservices сразу после установки (если нужно поменять значение, выбранное при установке системы). Во время жизни системы, лучше использовать команды cfgadm или svcadm, чтобы точно указать изменения. Действуя таким образом, вы не получите неприятных «сюрпризов».
На этом выпуск заканчивается. В следующем выпуске Узнаем: Solaris Secure by Default, я более подробно расскажу об изменениях в некоторых сервисах, так что Вы сможете не только увидеть, как все было сделано, но и изменить настройки в зависимости от Ваших требований и политик безопасности.

Похожие записи:

1. Безопасность по умолчанию в Solaris, часть 2
2. Безопасность по умолчанию в Solaris, часть 3
3. Top 5 средств безопасности Solaris 10, которые следует использовать

Впечатленный списком достоинств, с которым Solaris 10 выиграл награду InfoWorld 2008 Technology of the Year Award, я решил составить свой собственный список. Надеюсь, Вы меня простите, но просто я не мог удержаться…

Top 5 средств безопасности Solaris 10, которые следует использовать

Список предназначен для выделения пяти средств безопасности Solaris 10, которые принесут самую большую и быструю выгоду Вам и Вашей организации. Я остановился на пяти характерных особенностях, но Solaris может предложить гораздо больше, как показано в презентации. Во всяком случае, давайте перейдем к списку… (барабанная дробь, пожалуйста)…

5. Аудит.

Да, в Solaris есть аудит начиная с версии 2.3, но я не могу сосчитать сколько раз я говорил с людьми, которые не знают об этом. Аудит в Solaris – это хорошая возможность понять, что происходит с вашей системой. Аудит встроен в ядро, поэтому может видеть и записывать все, что происходит – это критично для организаций, которым необходимо соответствовать требованиям законодательства. Мартин опубликовал конфигурацию аудита, отвечающую требованиям безопасности индустрии платежных карт.  У нас также есть статья о том, как Solaris в целом выглядит в этой области, но я отклоняюсь от темы… Идем дальше.

4. Привилегии

Скорее всего, Вы используете привилегии, даже не зная об этом, и это хорошо. В Solaris реализован принцип наименьшего уровня привилегий, который действует в сервисах и set-uid приложениях. По-умолчанию в Solaris многим сервисам назначены только те привилегии, которым им нужны (или сервисы просто сбрасывают ненужные привилегии). Но на этом польза привилегий не заканчивается. В статье Sun BluePrint описывается, как интегрировать привилегии в стороннее приложение, или в Ваше собственное. Далее, для тех, кто занимается разработкой, эта статья рассказывает, как включить привилегии прямо в код, чтобы использовать технику privilege bracketing, еще сильнее ограничивая выполнение кода с высокими привилегиями. Не знаете, какие привилегии Вам нужны? Попробуйте наш отладчик привилегий – он Вам покажет. Вы можете существенно снизить риск повреждений, используя только те привилегии, которые нужны – и все мы согласимся, что это хорошо.

3. Управление доступом на основе ролей

Вам нужно ограничить доступ к функциям администратора? Вам нужно иногда выполнять привилегированные операции? Ответ – управление доступом на основе ролей (Role Base Access Control, RBAC). Изначально появившийся в Solaris 8, механизм RBAC все более тесно интегрируется с остальной операционной системой. Например, если Вы хотите разрешить операторам перезапускать, но не изменять сервисы системы, RBAC сможет Вам помочь. Барт разработал очень хороший тур по RBAC для новичков в этой технологии. Те, кто хочет чего-то более сложного, могут реализовать сценарий управления доступом «две персоны» (или «четыре глаза»). Независимо от того, хотите ли Вы просто делегировать некоторые функции суперпользователя,  или реализовать сложную политику управления доступом, RBAC может предоставить средства для всех Ваших потребностей.

2. Зоны

Вы знали, что я доберусь до зон, не так ли? ИМХО, зоны являются одним из важнейших средств безопасности в Solaris 10. Работающие в режиме ядра, и почти все, работающие в режиме пользователя вредоносные программы, по-существу выполняются без эффекта, когда приложение работает в не глобальной зоне sparse-root. Зоны выполняются с меньшим уровнем привилегий, чем их глобальный аналог, из-за этого атаки, ориентированные на привилегии, реализуются гораздо сложнее. Более того, основные исполняемые файлы ОС, библиотеки и модули ядра в конфигурации по-умолчанию являются неизменяемыми, т.к. они подключаются в режиме только для чтения из глобальной зоны. Что это означает? Проще говоря, Вы не можете изменить их. Это огромная победа для безопасности, управления изменениями, управления ИТ. Вы можете назначить доступ приложению так, чтобы оно работало в безопасном окружении, без риска изменения основной ОС. А если Вы хотите внести изменения, Solaris достаточно гибка, чтобы обеспечить это. Вы можете добавлять устройства, файловые системы, сетевые интерфейсы, даже привилегии зонам. Вы можете использовать различные механизмы управления ресурсами, чтобы предотвратить несправедливое использование ресурсов Solaris.  Еще вы можете персонализировать свою зону с помощью укрепления безопасности, сервисов имен и аутентификации, политики аудита и многого другого. Более интересные вещи можно делать с взаимодействующими зонами. Зоны предоставляют такие непреодалимые возможности безопасности, что (совместно с аудитом, привилегиями и RBAC) служат основой Solaris Trusted Extensions, многоуровневой операционной системой Sun, реализующей мандатное управление доступом.

1. Сетевая безопасность по-умолчанию

Последнее, но определенно не худшее в этом списке средство – сетевая безопасность по умолчанию (Secure by Default, SBD). SBD введена в Solaris 10 11/06 в целях существенного уменьшения области, доступной для сетевых атак, особенно в новых конфигурациях. Что? Это означает, что когда SBD включена во время установки, единственным сервисом, доступным по сети, будет Secure Shell (в отличие от обычного длинного списка сервисов, которые могут использоваться, или не использоваться в Вашем окружении). SBD может быть включена во время установки (для новых инсталляций), или после установки (во время обновления или просто когда Вы захотите ее включить). SBD либо выключит сервисы, которые считает некритичными, либо переведет критичные сервисы в режим локальной работы, при котором они будут отвечать на запросы только с локальной машины. Это позволяет Вам начать с более защищенной установки и включать только те сервисы, которые Вам действительно нужны. SBD может быть сконфигурирована в глобальной зоне, или в любом количестве неглобальных зон (т.к. все они могут иметь свою собственную конфигурацию). Те, кому нужны более гибкие настройки (какие сервисы могут быть разрешены, запрещены, установлен локальный режим и т.д.), могут рассмотреть возможность использования Solaris Security Toolkit, где можно задавать политики, описывающие допустимые конфигурации системы. Независимо от выбранных инструментов, сейчас Вы можете гораздо проще защитить свою инсталляцию ОС Solaris.

Надеюсь, Вы получили удовольствие от просмотра список Top 5 средств безопасности Solaris 10, которые следует использовать. Если вы хотите узнать больше о возможностях, которые предоставляет Solaris 10, есть много вариантов действий:

• Домашняя страница безопасности в Solaris 10
• Учебный центр безопасности в Solaris 10
• Установившаяся практика безопасности в Solaris 10
• Библиотека безопасности Solaris
• Презентации по безопасности Solaris
• Сообщество безопасности OpenSolaris
• Блоги Sun (метки Solaris+Security)

До следующего раза…

Глен.

Оригинал статьи: http://blogs.sun.com/gbrunett/entry/top_5_solaris_10_security

Похожие записи:

1. Безопасность по умолчанию в Solaris, часть 1
2. Конвертируем пользователя root в роль
3. Безопасность по умолчанию в Solaris, часть 3