Безопасность 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. Рекомендуется размещать в качестве первого символа точку (<.>) в имени файла (это скрывает файл от просмотра, поэтому его нельзя будет перепутать с функционирующим файлом). Если служба не понадобится в будущем, файл можно удалить.

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

Необходимо обязательно просмотреть файлы загрузки и определить, не запускаются ли необязательные службы (в следующем разделе рассказывается о том, как выявлять необязательные службы).

Совет

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

Службы, работу которых следует разрешить

Набор служб, выбранных для систем Unix, зависит от того, каким образом они будут использоваться. Некоторые из этих служб будут запускаться с помощью файлов загрузки; ряд служб контролируется через сервис inetd и настраивается в файле /etc/inetd.conf. Приведенный ниже текст представляет собой часть файла inetd.conf системы Solaris. Строки, начинающиеся с символа решетки <#> - комментарии.

#ident "@(#)inetd.conf 1.27 96/09/24 SMI"
/*SVr4.0 1.5 */
# Ftp and telnet are standard Internet services.
ftp stream tcp nowait root
/usr/sbin/in.ftpd in.ftpd
#telnet stream tcp nowait root /usr/sbin/in.telnetd
in.telnetd
#
# Shell, login, exec, comsat and talk are BSD protocols.
#shell stream tcp nowait root
/usr/sbin/in.rshd in.rshd
#login stream tcp nowait root /usr/sbin/in.rlogind
in.rlogind
#exec stream tcp nowait root
/usr/sbin/in.rexecd in.rexecd
#comsat dgram udp wait root
/usr/sbin/in.comsat in.comsat
#talk dgram udp wait root
/usr/sbin/in.talkd in.talkd
#
# Solstice system and network administration class agent server
#100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind

Файл inetd.conf не только контролирует службы типа FTP и telnet, но и некоторые службы RPC. Файл inetd.conf необходимо очень внимательно проверять на предмет того, что в нем сконфигурированы только необходимые службы. После правильной настройки файла необходимо перезапустить службу inetd посредством следующей команды:

#kill -HUP <номер процесса inetd>

Команда -HUP вызывает повторное считывание службой inetd ее конфигурационного файла.

Многие службы, настраиваемые по умолчанию на системах Unix, необходимо отключить. Ниже приведен перечень этих служб.

Chargen	rexd	Systat	
Discard	Routed	Tftp	
Echo	Rquotad	Uucp	
Finger	Rusersd	Walld	
netstat	sprayd

Кроме того, можно отключить службы 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.

Примечание

Неблагоразумно разрешать экспорт файловых систем во внешнюю среду из рассматриваемой организации.

Системы DMZ

Системы Unix, используемые в DMZ как веб-серверы, почтовые серверы или серверы DNS, должны настраиваться еще более тщательно с точки зрения безопасности, чем системы, используемые исключительно внутри сети. Такие системы, как правило, не требуют использования служб RPC и NFS. Эти две службы можно удалить посредством внесения изменений в файлы загрузки.

Серверы и рабочие станции

В некоторых организациях операционная система Unix используется как на серверах, так и на рабочих станциях. При использовании на рабочей станции система обычно настраивается на функционирование системы X Window System. На системах Solaris в этом случае используется программа ToolTalk (RPC-программа, предназначенная для связи между приложениями).

Эти службы не нужны на серверах, а службы DNS и routed не требуются на рабочих станциях. Необходимо разработать руководство по настройке серверов и руководство для настройки рабочих станций, если система Unix используется описанным выше образом.

Примечание

Программа ToolTalk контролируется посредством inetd.conf на системах Solaris. Чтобы отключить эту программу, необходимо закомментировать следующую строку:

100083/1 tli rpc/tcp wait root 
  /usr/dt/bin/rpc.ttdbserverd/usr/dt/bin/rpc.ttdbserverd.

Использование программ TCP Wrappers

Программы TCP Wrappers (доступны по адресу ftp://ftp.porcupine.org/pub/security) используются для обеспечения дополнительного уровня защиты в случае применения служб telnet или FTP. Как видно из названия, программы TCP Wrappers (wrap - оболочка) создают "оболочку" для служб telnet и FTP с целью обеспечения дополнительного контроля доступа и ведения журналов. Для использования программы TCP Wrappers необходимо настроить файл inetd.conf так, чтобы строки telnet и FTP выглядели следующим образом:

ftp stream tcp nowait root /usr/local/bin/tcpd /usr/sbin/in.ftpd
telnet stream tcp nowait root /usr/local/bin/tcpd /usr/sbin/in.telnetd

Эти строки вызывают запуск TCP Wrappers (tcpd) службой inetd, когда кто-либо пытается установить с системой сеанс связи через telnet или FTP.

Примечание

TCP Wrappers можно использовать и для других служб, таких как POP и IMAP. Нужно просто внести соответствующие изменения в строки конфигурации, представленные выше.

TCP Wrappers можно настроить на блокировку или разрешение определенным узлам или сетям доступа к службам telnet и FTP. Файлы, используемые для этих действий по настройке, - это файлы /etc/hosts.allow и /etc/hosts.deny. Синтаксис для работы с этими файлами выглядит следующим образом:

<имя программы-оболочки>:  <ip-адрес>/<маска сети>

Следующие файлы представляют собой примеры файлов конфигурации TCP Wrapper.

hosts.allow:
#Allow telnets from my internal network (10.1.1.x)
in.telnet: 10.1.1.0/255.255.255.0
#Allow ftp from the world
in.ftpd: 0.0.0.0/0.0.0.0
hosts.deny:
#Deny telnets from anywhere else
in.telnetd: 0.0.0.0/0.0.0.0

Файл hosts.allow оценивается в первую очередь, после чего обрабатывается файл hosts.deny. Следовательно, можно сначала настроить все системы, которым разрешено работать с различными службами, после чего запретить все остальное в файле hosts.deny. Кроме того, следует внести изменение в настройку журнала, чтобы разрешить TCP Wrappers заносить данные в журнал системы. Это изменение описано в разделе "Файлы журнала" далее в лекции.

Файлы конфигурации системы

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

Внимание!

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

Сообщения

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

Приветственное сообщение хранится в /etc/motd (сокр. от "message of the day" - сообщение дня). Однако это сообщение отображается не перед входом пользователя в систему, а после него. Большинство уведомлений, связанных с юридическими вопросами, необходимо отображать перед входом пользователя в систему.

Чтобы сообщение отображалось перед входом пользователя в систему, используйте следующий способ. В ОС Solaris предварительное уведомление хранится в каталоге /etc/default/telnetd. Можно создать сообщения входа для FTP посредством редактирования файла /etc/default/ftpd. Для создания сообщения добавьте в файл строку, аналогичную следующей:

BANNER="\n\n<Enter Your Legal Message Here\n\n"

Параметр \n означает новую строку. Поэкспериментируйте с символами новой строки, чтобы сообщение приняло нужный вам вид.

В системах Linux для сообщений telnet используются два файла: /etc/issue и /etc/issue.net. Файл issue применяется для терминалов, подключенных напрямую, а issue.net используется в том случае, когда кто-либо устанавливает по сети соединение через telnet с рассматриваемой системой. К сожалению, только на изменении этих файлов создание сообщения не закончится, так как они создаются заново при каждой загрузке системы. Однако можно изменить сценарий загрузки, создающий эти файлы.

Файлы создаются в сценарии загрузки /etc/rc.d/rc.local. Чтобы предотвратить автоматическое создание /etc/issue и /etc/issue.net, закомментируйте следующие строки /etc/rc.d/rc.local:

# This will overwrite /etc/issue at every boot. So, make any changes you
# want to make to /etc/issue here or you will lose them when you reboot.
echo "" > /etc/issue
echo "$R" > /etc/issue
echo "Kernel $(uname -r) on $a $SMP$(uname -m)" >> /etc/issue

После этого можно изменить /etc/issue и /etc/issue.net, введя в них соответствующий текст с заявлением о правах.

Настройки паролей

Существует три этапа процедуры управления паролями в системе Unix.

Настройка требований к паролю. В системах Unix требования к возрасту паролей и их длине устанавливаются посредством изменения файла конфигурации. В системе Solaris этим файлом является /etc/default/passwd. Файл содержит приведенные ниже строки, которые следует редактировать для соответствия политике безопасности организации.

#ident 	"@(#)passwd.dfl 	1.3 	92/07/14 SMI"
MAXWEEKS=7
MINWEEKS=1
PASSLENGTH=8

Внимание!

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

Вопрос к эксперту

Вопрос. Где системный администратор может узнать о том, как следует настроить систему?

Ответ. Определение требований к конфигурации систем всегда начинается с политики безопасности организации. В каждой организации должны быть разработаны процедуры конфигурации, специфичные для конкретной используемой системы; при этом необходимо руководствоваться политикой безопасности. Эти процедуры должны определять, каким образом следует настраивать систему с использованием конкретной операционной системы, чтобы обеспечить соответствие ОС требованиям политики безопасности.

В системах Linux требования к паролям находятся в файле /etc/login.defs. Следующие строки файла /etc/login.defs представляют собой настраиваемые параметры:

# Password aging controls:
#
#   PASS_MAX_DAYS Maximum number of days a password may be used.
#   PASS_MIN_DAYS Minimum number of days allowed between password changes.
#   PASS_MIN_LEN Minimum acceptable password length.
#   PASS_WARN_AGE Number of days warning given before a password expires.
#
PASS_MAX_DAYS 45
PASS_MIN_DAYS 1
PASS_MIN_LEN 8
PASS_WARN_AGE 7

Внимание!

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

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

Запрет на вход без пароля. Программы rlogin, rsh и rexec позволяют пользователям осуществлять вход в систему с определенных систем без указания пароля вручную. Этого делать не рекомендуется, так как злоумышленник, проникший в одну из систем, может таким образом получить доступ к остальным компьютерам. Помимо удаления служб rlogin, rsh и rexec из /etc/inetd.conf следует удостовериться в том, что файл /etc/host.equiv и любые файлы .rhost, имеющиеся в системе, найдены и удалены. Не забудьте также проверить домашние каталоги всех пользователей.

Указание требований к содержимому паролей. Запрет пользователям на выбор ненадежных паролей является одним из наилучших способов повышения уровня безопасности системы. К сожалению, до недавнего времени в системах Unix существовало несколько простых способов это сделать. Программы типа passwd+ и npasswd имеются для Linux, но не для Solaris. Обе эти программы позволяют указывать требования к надежности паролей и вынуждают пользователей выбирать пароли, соответствующие установленным правилам.

С выходом Solaris 2.6 и более поздних реализаций Linux появилось более совершенное средство отслеживания надежности паролей пользователей - это Pluggable Authentication Modules (PAM). Более подробная информация о PAM и о том, как создать фильтры паролей, находится по адресу http://www.sun.com/solaris/pam/; для системы Linux - по адресу ftp://ftp.kernel.org/pub/linux/libs/pam/index.html.

Примечание

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

Контроль доступа к файлам

В системе Unix доступ к файлам контролируется посредством набора разрешений. Для владельца файла, группы, которой принадлежит владелец, и для всех остальных лиц можно присваивать привилегии чтения, записи и выполнения. Файловые разрешения изменяются посредством команды chmod. Как правило, не рекомендуется разрешать пользователям создавать файлы, доступные для чтения или записи для любых лиц. Такие файлы могут считываться или записываться любым пользователем системы. Если злоумышленник получит доступ к идентификатору пользователя, он сможет считать или изменить любые из таких файлов.

Так как достаточно трудно убедить всех пользователей в необходимости изменять разрешения доступа к файлу при его создании, разумно создать механизм, используемый по умолчанию, предназначенный для настройки соответствующих разрешений при автоматическом создании файла. Это можно осуществить с помощью параметра unmask. В системах Solaris этот параметр располагается в файле /etc/default/login, в системах Linux - в /etc/profile. Команда выполняется следующим образом:

unmask 077

Цифры, указываемые после команды, определяют разрешения, которые не будут присвоены по умолчанию вновь создаваемому файлу. Первая цифра определяет разрешения относительно владельца файла, вторая цифра указывает разрешения для группы, а третья - для всех остальных пользователей. В случае, рассмотренном выше, все новые файлы присваивают разрешения чтения, записи и выполнения владельцу того или иного файла, а группе и всем остальным пользователям не предоставляется никаких разрешений.

Разрешения определяются числами следующим образом:

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

Доступ через корневую учетную запись

Как правило, рекомендуется ограничивать прямой доступ с использованием корневой учетной записи. При таком подходе даже администраторам необходимо сначала выполнить вход систему с использованием их аутентификационных данных, и только после этого с помощью команды su получить доступ к корневой учетной записи. Это также обеспечивает создание записей в журнале, отображающих, какие идентификаторы пользователей использовались для получения доступа к корневой учетной записи. В качестве альтернативы вместо команды su можно использовать команду sudo. Команда sudo обеспечивает дополнительные возможности по ведению журналов, заключающиеся в фиксировании команд, выполняемых пользователями, работающими в корневой учетной записи.

Существует возможность ограничить вход под корневой учетной записью таким образом, чтобы его можно было осуществлять только из консоли Solaris или Linux. В системе Solaris следует изменить файл /etc/default/login и убедиться в том, что следующая строка не закомментирована:

# If CONSOLE is set, root can only login on that device.
# Comment this line out to allow remote login by root.
#
CONSOLE=/dev/console

Посредством этого система разрешит прямой вход в корневую учетную запись только через консоль. В системе Linux можно реализовать аналогичную конфигурацию, редактируя файл /etc/securetty. Этот файл представляет собой список TTY, которые используются для входа в корневую учетную запись. Содержимым этого файла должно быть /dev/tty1. Если для управления системой используется последовательный канал связи, файл должен содержать /dev/ttyS0. Сетевые TTY - это, как правило, /dev/ttyp1 и выше.

Если требуется контролировать корневой доступ к системе, рекомендуется осуществлять контроль корневого доступа к FTP. Файл /etc/ftpusers и в системах Solaris, и в системах Linux представляет перечень учетных записей, которым не разрешено осуществлять доступ к системе через FTP. Убедитесь, что в данном списке присутствует корневая учетная запись.

Защита от переполнения буфера

Переполнение буфера - одна из наиболее серьезных опасностей, угрожающих системе. Solaris предоставляет способ предотвращения выполнения команд вне стека при проявлении атак на переполнение буфера (см. лекцию 3 для получения более подробной информации о переполнении буфера). Для этого необходимо добавить следующие строки в файл /etc/system:

set noexec_user_stack=1
set noexec_user_stack_log=1

Первая строка предотвращает выполнение команд вне стека, а вторая - заносит в журнал данные о произведенных попытках.

Внимание!

Существует ряд программ, которым требуется выполнять команды вне стека. Если внести описанное изменение, то при работе этих программ возникнут сбои. Убедитесь, что данная команда протестирована, прежде чем применять ее на системах.

Существует несколько других проектов, предназначенных для повышения уровня защиты стека Linux. Один из них расположен по адресу http://www.openwall.com/linux/.

Отключение неиспользуемых учетных записей

В Unix создается набор учетных записей, необходимых для различных целей (например, владение некоторыми определенными файлами), которые никогда не используются для входа в систему. Такими учетными записями являются sys, uucp, nuucp и listen. Для каждой учетной записи следует изменить их записи в файле /etc/shadow, чтобы предотвратить успешный вход в систему с их помощью:

root:XDbBEEYtgskmk:10960:0:99999:7:::
bin:*LK*:10960:0:99999:7:::
daemon:*LK*:10960:0:99999:7:::
adm:*LK*:10960:0:99999:7:::
lp:*LK*:10960:0:99999:7:::
sync:*LK*:10960:0:99999:7:::
shutdown:*LK*:10960:0:99999:7:::
halt:*LK*:10960:0:99999:7:::
mail:*LK*:10960:0:99999:7:::
news:*LK*:10960:0:99999:7:::
uucp:*LK*:10960:0:99999:7:::
operator:*LK*:10960:0:99999:7:::
games:*LK*:10960:0:99999:7:::
gopher:*LK*:10960:0:99999:7:::
ftp:*LK*:10960:0:99999:7:::
nobody:*LK*:10960:0:99999:7:::

Второе поле в каждой строке представляет собой поле пароля. В случае с обычными пользовательскими учетными записями здесь располагается зашифрованный пароль. Для учетных записей, вход посредством которых запрещен, второе поле должно содержать какие-либо данные с символом "*". Символ "*" не соответствует ни одному реальному паролю и, таким образом, не может быть угадан или взломан. Посредством размещения в поле пароля соответствующих символов, таких как "LK", можно явным образом сообщать о том, что данная учетная запись заблокирована.

Обновления

Для исправления ошибок и устранения уязвимостей для Unix выпускаются обновления и "заплатки" аналогично тому, как это делается для операционных систем семейства Windows. Обновления должны устанавливаться регулярно, чтобы минимизировать число уязвимостей. Различные поставщики систем Unix выпускают средства, помогающие в управлении обновлениями. Компания Sun предлагает программу Solaris Sunsolve Patch Manager, а Red Hat имеет онлайн-систему обновления в интернете (http://www.redhat.com/apps/support/errata/).

Примечание

При загрузке обновлений для систем Solaris имейте в виду, что Sun размещает многие обновления в кластере обновлений. Однако кластер обновлений может не содержать некоторых обновлений безопасности. Может понадобиться загрузить их в отдельном порядке и установить вручную.

Вопросы для самопроверки

Управление пользователями

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

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

Добавление пользователей в систему

В большей части версий Unix имеются утилиты для добавления пользователей в систему. Здесь ключевыми задачами являются следующие.

Примечание

Большая часть систем содержит утилиты по добавлению пользователей для обеспечения автоматического выполнения этой задачи. В Linux для этого предназначена программа adduser. В системе Solaris эта утилита называется useradd.

Добавление имени пользователя в файл паролей

Файл /etc/passwd содержит перечень всех имен пользователей, принадлежащих пользователям системы. Каждый пользователь должен иметь уникальное имя, состоящее из восьми или менее символов. Для каждой записи в файле паролей должно быть определено реальное лицо, ответственное за учетную запись. Данную информацию можно добавить в поле GECOS (пятое поле в каждой строке).

Присвоение соответствующего идентификационного номера пользователя

Каждому имени пользователя необходимо присвоить соответствующий идентификатор пользователя (UID). UID должен быть уникальным в рамках всей системы. Как правило, идентификатор пользователя должны быть больше 100. Он ни в коем случае не должен быть равен 0, так как это идентификатор корневой учетной записи.

Внимание!

Система использует UID для идентификации владельцев файлов в системе и, таким образом, не рекомендуется даже повторное использование UID.

Присвоение соответствующего группового идентификатора

Каждый пользователь должен иметь главную группу. Присвойте этот номер имени пользователя в файле /etc/passwd. Обычные пользователи не должны быть членами группы "wheel", так как она используется в административных целях.

Определение соответствующей оболочки для входа в систему

Интерактивным пользователям необходимо предоставить оболочку для входа в систему. Как правило, это оболочки ksh, csh или bash. Пользователям, которые не будут осуществлять вход в систему, нужно предоставить программу, не являющуюся оболочкой. Например, если имеются пользователи, которые только проверяют электронную почту через POP или IMAP, им можно разрешить изменять свои пароли в интерактивном режиме. В данном случае существует возможность определить оболочку, указав в качестве нее /bin/passwd. При каждом подключении пользователей к системе через telnet им будет предоставляться возможность изменить пароль. По завершении этой операции пользователь будет выходить из системы.

Добавление имени пользователя в файл shadow

Пароли не должны храниться в файле /etc/passwd, так как этот файл доступен для чтения всем пользователям, и с его помощью злоумышленник может осуществить взлом пароля. Пароли должны храниться в файле /etc/shadow. Следовательно, имя пользователя должно быть добавлено и в файл /etc/shadow.

Присвоение соответствующего начального пароля

После создания учетной записи следует установить начальный пароль. Большая часть утилит, используемая для добавления пользователей в системы, предлагает сделать это автоматически. В противном случае нужно войти в систему как пользователь и выполнить команду passwd. После этого появится предложение указать пароль для учетной записи. Начальные пароли должны быть сложными для угадывания, и рекомендуется не использовать один и тот же начальный пароль для всех учетных записей. Если используется один и тот же начальный пароль, атакующий может использовать новые учетные записи, прежде чем у легального пользователя появится возможность войти в систему и изменить пароль.

Определение соответствующего псевдонима электронной почты

При создании пользователя он автоматически получает адрес электронной почты <имя_пользователя@host. Если пользователь хочет иметь другой адрес электронной почты, такой как имя.фамилия@host, то этот адрес можно присвоить посредством псевдонима электронной почты. Чтобы добавить псевдоним, измените файл /etc/aliases. Формат этого файла таков:

Alias: username

После создания псевдонима необходимо запустить программу newaliases, чтобы создать файл alias.db.

Создание домашнего каталога для пользователя

Каждый пользователь должен иметь свой собственный домашний каталог. Этот каталог определяется в файле /etc/passwd. После создания каталога в соответствующем месте в системе (как правило, это каталог /home или /export ), владельцем каталога назначается пользователь командой chown следующим образом:

chown <username> <directory name>

Удаление пользователей из системы

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

Изначально, если пользователю больше не требуется учетная запись, ее следует заблокировать. Это можно сделать посредством замены пароля пользователя в файле /etc/shadow символами <*LK*>. По прошествии определенного числа дней (как правило, 30 дней), файлы пользователя могут быть удалены. Время, отведенное менеджеру пользователя на копирование или удаление файлов пользователя, требуемых организации, равно 30 дням.

Управление системой

Управление системой Unix (относительно вопросов безопасности) заключается в ведении журнала и отслеживании системы на наличие признаков подозрительной активности. Системы Unix предоставляют достаточное количество информации о том, что происходит в системе, а также набор средств, которые могут использоваться для выявления подозрительной активности.

Аудит системы

В большинстве случаев ведение системных журналов является стандартной процедурой, выполняемой в большинстве версий Unix, и в них заносится достаточный объем данных, связанных с безопасностью системы. В некоторых ситуациях требуется проведение дополнительного аудита. В Solaris для этого предусмотрен модуль Basic Security Module (BSM). BSM не включен в Solaris по умолчанию. Необходимость в дополнительных возможностях здесь определяется пользователем.

Чтобы включить BSM, выполните сценарий /etc/security/bsmconv. При этом запустится фоновая программа аудита, но перезагрузка системы не потребуется. Файл /etc/security/audit_control используется для определения конфигурации аудита. Полная информация по этому файлу находится в инструкции к ОС (man audit_control), однако для начала рекомендуется использовать следующую конфигурацию:

#identify the location of the audit file directory
dir: <directory>
#identify the file system free space percentage when a warning should occur
minfree: 20
#flags for what to audit. This example audits login, administrative
#functions and failed file reads, writes, and attribute changes
flags: lo,ad,-fm
#This set of flags tells the system to also audit login and administrative
#events that cannot be attributed to a user
naflags: lo,ad

Как только файл будет настроен, начнут создаваться записи аудита. Для закрытия текущего файла записи аудита и открытия нового файла используется команда audit -n. Команда praudit <имя файла аудита> предназначена для просмотра содержимого файла аудита.

Внимание!

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

Файлы журналов

Большая часть систем Unix обеспечивает довольно широкие возможности по ведению журналов в программе syslog. Syslog - это фоновая программа, выполняющаяся и фиксирующая данные журнала согласно настройке. Syslog настраивается через файл /etc/syslog.conf. Следует заметить, файлы журналов должны просматриваться только корневым пользователем, и никто не должен иметь возможности их изменять.

Большая часть файлов syslog.conf направляет сообщения журналов в /var/log/messages или /var/adm/log/messages. Правильно написанный syslog.conf должен содержать следующую команду конфигурации:

auth.info /var/log/auth.log

С помощью этой команды Unix собирает информацию о попытках входа, попытках выполнения команды su, перезагрузке системы и других событиях, так или иначе связанных с безопасностью системы. Данная команда также позволяет программам TCP Wrappers заносить информацию в файл auth.log. Обязательно создайте файл /var/log/auth.log для фиксирования этой информации:

#touch 	/var/log/auth.log
#chown 	root /var/log/auth.log
#chmod 	600 /var/log/auth.log

В Solaris при создании файла /var/adm/loginlog можно фиксировать неудачные попытки входа в систему. Создайте файл следующим образом:

#touch	 /var/adm/loginlog
#chmod 	600 /var/adm/loginlog
#chown 	root /var/adm/loginlog
#chgrp 	sys /var/adm/loginlog

Убедитесь, что /var предоставлено достаточное количество свободного пространства для ведения файлов журнала. Если /var расположен в том же разделе, что и /, корневая файловая система переполнится при сильном увеличении файлов журнала. Рекомендуется размещать каталог /var в другой файловой системе.

Скрытые файлы

Скрытые файлы представляют собой потенциальную проблему для систем Unix. Любой файл, начинающийся с точки (<.>), не отображается при выполнении стандартной команды ls. Однако при использовании команды ls -a отобразятся все скрытые файлы. Хакеры научились использовать скрытые файлы для маскировки своих действий. Злоумышленник может просто скрыть свои файлы в скрытом каталоге. В других ситуациях хакеры могут скрывать файлы в каталогах, которые трудно обнаружить администратору. Например, если назвать каталог <...>, то он может остаться незамеченным. Добавление пробела после третьей точки (<...>) делает каталог труднодоступным, если не знать о наличии пробела. Чтобы отобразить все скрытые файлы и каталоги, имеющиеся в системе, выполните следующую команду:

#find / -name '.*' -ls

Использование -ls вместо -print позволяет вывести более подробный список расположения файла. Следует периодически выполнять эту команду и проверять любые новые скрытые файлы.

Файлы SUID и SGID

Файлы, для которых разрешены полномочия Set UID (SUID) или Set Group ID (SGID), могут изменять идентификатор своего активного пользователя или группы в процессе выполнения. Некоторым файлам требуется такая возможность для выполнения своей работы, однако это должен быть ограниченный набор файлов, и ни один из них не должен находиться в домашних каталогах пользователей. Чтобы найти все файлы SUID и SGID, выполните следующие команды:

#find 	/ 	-type f -perm -04000 -ls
#find 	/ 	-type f -perm -02000 -ls

При построении системы необходимо выполнить данные команды и сохранить результаты их выполнения. Периодически следует выполнять эти команды и сопоставлять результаты с исходным списком. Любые обнаруженные изменения необходимо исследовать.

Файлы, доступные для записи всем пользователям

Файлы, общедоступные для записи, являются еще одной потенциальной ошибкой в конфигурации системы Unix. Такие файлы позволяют злоумышленнику создать сценарий, который при выполнении будет использовать уязвимость. Если файлы SUID и SGID доступны для записи всем пользователям, у атакующего появляется возможность создать для самого себя самые обширные привилегии. Чтобы выявить все файлы, общедоступные для записи, выполните следующую команду:

#find   /    -perm -2 -type f -ls

Следует периодически выполнять эту команду, чтобы находить все общедоступные для записи файлы, имеющиеся в системе.

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

Мы уже описали некоторые признаки, которые необходимо отслеживать в системе и которые могут означать проявление угрозы или проникновение в систему (скрытые файлы, файлы SUID и SGID и общедоступные для записи файлы). Существует несколько других способов проверки системы Unix на наличие подозрительной активности.

Смешанный режим

Интерфейс находится в смешанном режиме, когда в системе работает сниффер (сетевой анализатор пакетов). Сниффер переводит интерфейс в смешанный режим; при этом происходит фиксирование всей информации, проходящей через канал связи. Если при работе интерфейса в данном режиме выполнить команда ifconfig -a, то появится сообщение о том, что интерфейс находится в состоянии PROMISC (признак того, что работает анализатор пакетов). Если сниффер запущен не администратором системы, необходимо провести исследование причин этих обстоятельств.

Примечание

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

netstat

Программа netstat используется для выяснения того, какие сетевые соединения находятся в активном состоянии в системе Unix. Команду следует использовать следующим образом: netstat -an. Аргумент "n" сообщает netstat о том, что обработка IP-адресов не требуется.

#netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address 	Foreign Address 		State
tcp 	0 	0 0.0.0.0:10000 		0.0.0.0:* 				LISTEN
tcp 	0 	0 0.0.0.0:25 			0.0.0.0:* 				LISTEN
tcp 	0 	0 0.0.0.0:515 			0.0.0.0:*  				LISTEN
tcp 	0 	0 0.0.0.0:98 			0.0.0.0:*  				LISTEN
tcp 	0 	0 0.0.0.0:113 			0.0.0.0:*  				LISTEN
tcp 	0 	0 0.0.0.0:79 			0.0.0.0:*  				LISTEN
tcp 	0 	0 0.0.0.0:513 			0.0.0.0:*  				LISTEN
tcp 	0 	0 0.0.0.0:514 			0.0.0.0:*  				LISTEN
tcp 	0 	0 0.0.0.0:23 			0.0.0.0:*  				LISTEN
tcp 	0 	0 0.0.0.0:21 			0.0.0.0:*  				LISTEN
tcp 	0 	0 0.0.0.0:111 			0.0.0.0:*  				LISTEN
udp 	0 	0 0.0.0.0:10000 		0.0.0.0:*
udp 	0 	0 0.0.0.0:518 			0.0.0.0:*
udp 	0 	0 0.0.0.0:517 			0.0.0.0:*
udp 	0 	0 0.0.0.0:111 			0.0.0.0:*
raw 	0 	0 0.0.0.0:1 			0.0.0.0:*  				
raw 	0 	0 0.0.0.0:6 			0.0.0.0:*

Как видно из результирующих данных, любая строка, содержащая слово "LISTEN", означает, что имеется программа, прослушивающая этот порт. Прослушиваться должны только сконфигурированные администратором порты. Если в системе присутствует прослушиваемый порт, который не конфигурировался администратором, систему необходимо проверить и выяснить, почему порт открыт.

Адреса, отображаемые в столбце локальных адресов, заканчиваются номером локального порта (число после столбца). Этот номер порта используется для определения того, является ли соединение входящим или исходящим. Например, если номер локального порта 23, то это входящее подключение к демону telnet. Если номер локального порта равен 1035, а номер внешнего порта - 23, то это исходящее соединение telnet.

lsof

Одна из проблем, связанных с программой netstat, заключается в том, что данная команда не сообщает, какой процесс поддерживает открытое состояние порта. Поиск процесса, связанного с определенным портом, может стать очень трудной задачей. Однако существует программа под названием lsof (http://ftp.cerias.purdue.edu/pub/tools/unix/sysutil/Isof/), которая предоставляет такую информацию. Сразу после установки программы выполните команду lsof -i, как показано ниже:

#lsof -i
COMMAND 	PID 	USER 	FD 	TYPE	DEVICE SIZE     NODE NAME
portmap 	311 	root 	4u 	IPv4 	301 		UDP 	*:sunrpc
portmap 	311 	root 	5u 	IPv4 	302 		TCP 	*:sunrpc (LISTEN)
inetd 		439 	root 	5u 	IPv4 	427 	TCP 	*:ftp (LISTEN)
inetd 		439 	root 	6u 	IPv4 	428 	TCP 	*:telnet (LISTEN)
inetd 		439 	root 	7u 	IPv4 	429 	TCP 	*:shell (LISTEN)
inetd 		439 	root 	9u 	IPv4 	430 	TCP 	*:login (LISTEN)
inetd 		439 	root 	10u 	IPv4 	431 	UDP 	*:talk
inetd 		439 	root 	11u 	IPv4 	432 	UDP 	*:ntalk
inetd 		439 	root 	12u 	IPv4 	433 	TCP 	*:finger (LISTEN)
inetd 		439 	root 	13u 	IPv4 	434 	TCP 	*:auth (LISTEN)
inetd 		439 	root 	14u 	IPv4 	435  	TCP 	*:linuxconf (LISTEN)
lpd 		455 	root 	6u 	IPv4 	457  	TCP 	*:printer (LISTEN)
sendmail 	494 	root 	4u 	IPv4 	495  		TCP 	*:smtp (LISTEN)
miniserv. 	578 	root 	4u 	IPv4 	567  		TCP 	*:10000 (LISTEN)
miniserv. 	578 	root 	5u 	IPv4 	568  		UDP 	*:10000

Как видно из результатов выполнения программы, lsof выводит перечень всех открытых портов с указанием того, какие процессы поддерживают открытое состояние портов. Убедитесь, что вам известно, какие функции выполняет каждый процесс, и почему открыт соответствующий ему порт.

Примечание

lsof заменяет номер порта в столбце справа именем порта, если оно присутствует в файле /etc/services.

ps

Администратор также должен изучать результаты выполнения команды ps. Эта программа выводит все активные процессы, имеющиеся в системе, что необходимо при поиске снифферов, так как сниффер может не отображаться в lsof или в netstat. В большинстве систем выполнение команды ps -ef выводит перечень процессов в системе. В тех версиях Unix, где эта команда не работает, следует выполнить команду ps -aux. Результаты выполнения данной команды показаны ниже:

#ps -ef
UID 	PID 	PPID 	C 	STIME 	TTY 	TIME 	CMD
root 	1 	0 	0 	13:09 	? 	00:00:04 	init
root 	2 	1 	0 	13:09 	? 	00:00:00 	[kflushd]
root 	3 	1 	0 	13:09 	? 	00:00:00 	[kupdate]
root 	4 	1 	0 	13:09 	? 	00:00:00 	[kpiod]
root 	5 	1 	0 	13:09 	? 	00:00:00 	[kswapd]
root 	6 	1 	0 	13:09 	? 	00:00:00 	[mdrecoveryd]
bin 	3 11 	1 	0 	13:09 	? 	00:00:00 	portmap
root 	327 	1 	0 	13:10 	? 	00:00:00 	/usr/sbin/apmd -p 10 -w 5 -W
root 	380 	1 	0 	13:10 	? 	00:00:00 	syslogd -m 0
root 	391 	1 	0 	13:10 	? 	00:00:00 	klogd
daemon 	407 	1 	0 	13:10 	? 	00:00:00 	/usr/sbin/atd
root 	423 	1 	0 	13:10 	? 	00:00:00 	crond
root 	439 	1 	0 	13:10 	? 	00:00:00 	inetd
root 	455 	1 	0 	13:10 	? 	00:00:00 	lpd
root 	494 	1 	0 	13:10 	? 	00:00:00 	sendmail: accepting connections
root 	511 	1 	0 	13:10 	? 	00:00:00 	gpm -t ps/2
xfs 	528 	1 	0 	13:10 	? 	00:00:00 	xfs -droppriv -daemon -port -1
root 	570 	1 	0 	13:10 	tty1 	00:00:00 	login - root
root 	571 	1 	0 	13:10 	tty2 	00:00:00 	/sbin/mingetty tty2
root 	572 	1 	0 	13:10 	tty3 	00:00:00 	/sbin/mingetty tty3
root 	573 	1 	0 	13:10 	tty4 	00:00:00 	/sbin/mingetty tty4
root 	574 	1 	0 	13:10 	tty5 	00:00:00 	/sbin/mingetty tty5
root 	575 	1 	0 	13:10 	tty6 	00:00:00 	/sbin/mingetty tty6
root 	578 	1 	0 	13:10 	? 	00:00:00 	perl /usr/libexec/webmin/miniser
root 	579 	570 	0 	13:10 	tty1 	00:00:00 	-bash
root 	621 	579 	0 	13:17 	tty1 	00:00:00 	ps -ef

Следует периодически проверять список процессов, работающих в системе. Если обнаруживается что-либо незнакомое, то необходимо выяснить, что это такое.

Измененные файлы

Когда злоумышленник успешно проникает в систему, он может попытаться изменить системные файлы для обеспечения продолжительного доступа к системе. Файлы, передаваемые в систему, обычно называются "rootkit", так как позволяют злоумышленнику осуществить доступ через корневую (root) учетную запись. В дополнение к таким программам, как снифферы, rootkit может содержать двоичные замещения для следующих файлов:

ftpd	passwd	
inetd	ps	
login	ssh	
netstat	telnetd

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

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

Совет

По адресу http://www.chkrootkit.org/ можно найти утилиту, которая помогает в проверке наличия в системе rootkit-ов.

Аудит системы Unix

Этот проект покажет пути проверки систему Unix на ошибки в конфигурации или на наличие неизвестных процессов и учетных записей.

Шаг за шагом

Выводы

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

Контрольные вопросы