Безопасность Unix

Одной из основ безопасности этих систем является система прав доступа. Все файлы в файловых системах Unix могут иметь различные права на доступ в зависимости от установленных атрибутов. Права файла обычно задаются с помощью команды chmod, а отображаются при помощи команды ls.

Например:

-r-xr-xr-x 1  root  wheel  745720  28 ноя 2011  /bin/sh

Права Unix позволяют разграничивать доступ к файлу для разных пользователей; пользователи могут объединяться в группы с разными уровнями разрешений. Более сложные файловые системы поддерживают контрольные списки доступа (ACL), которые позволяют выдавать индивидуальные права нескольким пользователям или группам.

Например:

/pvr [u::rwx,g::r-x,o::r-x/u::rwx,u:Petr:rwx,g::r-x,m::rwx,o::r-x]

В этом примере (вывод команды chacl) пользователю Petr предоставлены права на запись в каталог /pvr.

Пользователи Unix-систем часто входят в группы с определёнными правами доступа, что позволяет организовать и централизовать управление полномочиями. Во многих Unix-реализациях дополнительно вводится уровень защиты, при котором для использования команды su требуется членство в группе привилегий пользователей wheel^[1].

В большинстве Unix и Unix-подобных систем существует учётная запись или группа, позволяющая получить полный контроль над системой — так называемый root. Если неавторизованный пользователь получает доступ к этой учётной записи, это означает полный компромисс безопасности платформы. Тем не менее, для системного администрирования необходим root-аккаунт, который, однако, не применяется для обычной работы и может быть отслежен для повышения безопасности.

Чтобы проиллюстрировать статус root-пользователя допускается аналогия с персонажем Супермен: root — это как Супермен с обычной учётной записью в роли Кларка Кента. Кларк Кент становится Суперменом только когда это необходимо для спасения; затем снова «превращается» в обычного пользователя. Root-доступ следует использовать по такому же принципу.

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

Выбор надёжного пароля и его защита — пожалуй, главное действие пользователя для повышения безопасности Unix. В системах семейства Unix важнейшие сведения о паролях хранятся в файле /etc/passwd, где записаны все пользователи и основные параметры их учётных записей. Хэши паролей раньше также хранились в этом файле:

nickname:password_hash:UserID:GroupID:Complete_Name:home_dir:shell_bin

Например:

xfze:$1$zuW2nX3sslp3qJm9MYDdglEApAc36r/:1000:100:José Carlos D. S. Saraiva:/home/xfze:/bin/bash

Поскольку все пользователи должны иметь права на чтение этого файла (для проверки пароля при входе), возникла уязвимость: любой мог видеть хэши паролей. Для устранения этого недостатка был введён файл /etc/shadow, доступ к которому имеет только root; в этом файле хранятся хэши паролей, а во втором поле строк в /etc/passwd ставится «x» для указания, что хэш нужно искать в /etc/shadow.

Файл /etc/shadow обычно содержит две ключевые позиции:

xfze:$1$zuW2nX3sslp3qJm9MYDdglEApAc36r/:::::

Остальные поля в /etc/shadow задают:

1. Минимальный срок (в днях) между сменой пароля
2. Максимальный срок действия пароля
3. Количество дней, за которое пользователь будет предупреждён о необходимости смены пароля
4. Количество дней, после которых, если пароль не изменён, учётная запись блокируется
5. Дата (число дней от 1 января 1970 года), когда истекает срок действия учётной записи

Эти параметры позволяют принудительно контролировать работу с паролями, что повышает защищённость Unix-системы.

Администраторы должны регулярно удалять устаревшие и неиспользуемые учётные записи.

• su, sudo, ssh

Как и любое программное обеспечение, операционные системы могут иметь уязвимости или нуждаться в усовершенствованиях. Надёжное обновление (патчинг) требует, чтобы ПО поступало из доверенного источника и не было изменено до попадания в дистрибутив. Типовые способы проверки, не был ли патч модифицирован, — применение криптографических хэшей, MD5 или использование носителей только для чтения. С точки зрения безопасности, формат упаковки (например, RPM пакеты в Red Hat Linux) менее важен, чем обеспечение целостности установки.

Дистрибуции, предоставляющие исходные тексты, позволяют пользователю изучить их на наличие подозрительных компонентов. Однако у этого подхода есть минус — пользователю или администратору необходимо владеть достаточными навыками для анализа кода.

В дистрибуциях Linux, использующих формат RPM, при обновлении системных компонентов и ПО для проверки целостности и аутентичности применяются MD5 и GPG. Значения хэшей включаются непосредственно в RPM-файл и проверяются при установке.

В Linux-дистрибутивах, использующих Debian и .deb-пакеты, безопасность достигается цифровой подписью — GPG-подписи вычисляются при создании пакета и проверяются в момент установки.

Независимо от вендора, все дистрибуции должны обеспечивать механизмы проверки подлинности ПО и его неизменности с момента упаковки.

Неиспользуемое ПО не должно устанавливаться и настраиваться в системе. Программы, которые долгое время не востребованы, должны быть полностью удалены.

Выявление активных служб:

• netstat -na
• lsof
• nmap
• sockstat -4 (FreeBSD)

inetd и xinetd выступают как супер-серверы для сетевых протоколов, например rlogin, telnet, FTP и др.

Отключение ненужных сервисов:

• с помощью команды chkconfig^[2] в Red Hat Linux
• через /etc/rc.conf и /usr/local/etc/rc.d в FreeBSD (/etc/rc.local)
• с помощью rc-update в Gentoo Linux

Такой подход называют проактивной безопасностью. Некоторые ОС считаются изначально безопасными; в частности, свободные BSD-системы (FreeBSD, NetBSD, OpenBSD) считаются более защищёнными. Пример вывода netstat на рабочей станции под управлением NetBSD 3.0:

$ netstat -a
 Active Internet connections (including servers)
 Proto Recv-Q Send-Q  Local Address          Foreign Address        State
 tcp        0      0  localhost.smtp         *.*                    LISTEN
 tcp        0      0  *.ssh                  *.*                    LISTEN
 Active Internet6 connections (including servers)
 Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
 tcp6       0      0  localhost.smtp         *.*                    LISTEN
 tcp6       0      0  *.ssh                  *.*                    LISTEN
 Active UNIX domain sockets
 Address  Type   Recv-Q Send-Q    Inode     Conn     Refs  Nextref Addr
 c0d10d80 dgram       0      0 0 c0cd8680        0 c0cb7000 -> /var/run/log
 c0cb7000 dgram       0      0 0 c0cd8680        0        0 -> /var/run/log
 c0cd8680 dgram       0      0 cb9639e8        0 c0d10d80        0 /var/run/log

Пример с системы BSD:

$ sockstat -4
 USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
 root     sendmail   569    4 tcp    localhost.smtp        *.*
 root     sshd       593    4 tcp    *.ssh                 *.*

Этот вывод демонстрирует, что сервис SSH слушает внешние сетевые интерфейсы, а Sendmail слушает только локальный интерфейс. Доступ к сервису можно ещё больше ограничить с помощью межсетевого экрана.