Гальвин Питер. The Solaris Security

Подождите немного. Документ загружается.

ftp stream tcp nowait root /usr/local/bin/tcpd /usr/local/bin/wu-ftpdtelnet

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

Заметьте, что мы уже используем tcpd для контролирования доступа к обоим сервисам и

используем wu-ftpd вместо простого ftp-сервера, который поставляется с Solaris-ом.

Если Вы не хотите разрешать доступ посредством telnet-а или ftp в Вашу систему,

просто удалите подходящую строку из inetd.conf или удалите этот файл, после чего,

процесс inetd просто не будет запускаться при загрузке системы.

Управление доступом для tcpd осуществляется с использованием файлов /etc/hosts.allow и

/etc/hosts.deny. tcpd просматривает сначала hosts.allow, следовательно, Вы можете

разрешить нескольким компьютерам подсоединияться к сервисам telnet или ftp и затем

запретить всем остальным доступ, в файле hosts.deny (часто это называют политикой

"запрещено все, что не разрешено"). Ниже идет пример файла hosts.allow:

ALL: 172.16.3.0/255.255.255.0

Этот пример разрешает всем пользователям сети 172.16.3.0 получить доступ ко всем

сервисам (telnet и ftp) на Вашей машине. Эти пользователи все равно должны

предоставить необходимый пароль или S/Key (см ниже). В файле hosts.allow всегда

используйте именно IP-адрессацию, так как доменные имена могут быть подделанны

(если Вы используете DNS через Internet или другие сервисы имен, такие как NIS).

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

следующую строку в файл /etc/hosts.deny:

ALL: ALL: /usr/bin/mailx -s "%d: connection attempt from %c"

root@mydomain.com

Такая установка не только запретит использование всех ресурсов со всех остальных

компьютеров, но и заставит tcpd просигнализировать Вам посредством электронной

почты, что кто-то пытается получить доступ на сервере. Вместо root@mydomain.com,

подставьте e-mail адрес того, кто читает почту регулярно.

Теперь, необходимо заставить tcpd записывать все попытки доступа через syslog.

Вставьте следующие строки в файл /etc/syslog.conf:

auth.auth.notice;auth.info /var/log/authlog

Пробел в строке необходимо делать именно табуляцией, иначе syslog не сможет

правильно проанализировать файл и регистрации никакой не получится. Кстати, средство

регистрации это конфигурируемый параметр при компилировании tcpd, но все равно

рекуомендуется использовать AUTH, а не средства LOCAL*.

 Другие файлы в /etc/init.d: Каспер повторяет, что выбор скриптов, которые нужно

удалить из /etc/init.d сильно зависит, от той версии Solaris-а, которую Вы используете.

Список файлов, предоставленный выше, был предоставленн для Solaris 2.4. Поэтому,

желательно знать, что Вы делаете, при конфигурации систем Solaris 2.5

 Sendmail: Вместо того, чтобы вызывать sendmail из cron-а, Вы можете также вызывать

программу без параметров -bd. Это заставит ее быть только в ожидающем очередь

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

работающем участке кода, но Вы можете поступить по своему.

 /etc/syslog.conf: Мы допустили ошибку в командах для конфигурирования

/etc/syslog.conf для tcpd. Правильная строка выглядит так

auth.info /var/log/authlog

Эта управляющая команда позволит регистрировать все события авторизации в файл /var/

log/authlog. Не забудьте, что пустое место это табуляция.

5.6) Конфигурирование системы S/Key

Вам понадобится пакет S/Key, для удаленного и защищенного доступа в систему (часть

пакета logdaemon). S/Key, это механизм одноразового пароля. Вместо того, чтобы

печатать свой пароль и посылать его через всю сеть, S/Key пошлет Вам "challenge"-строку,

и Вы вычислите ответ на вашем локальном компьютере, используя эту строку и свой

пароль. Если Вы пошлете соответствующий ответ, то S/Key даст Вам доступ к серверу, но

ответ, который Вы послали, никогда больше не будет верным для получения доступа к

машине. Это означает, что, если кто-то использует перехватчик пакетов, они не смогут

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

su, которая использует медод запрос/ответ для того, чтобы дать защищенный доступ

администратору сети.

Чтобы начинать использовать S/Key, создайте пользователя, который использует

/usr/local/bin/keysh как оболочку для входа в систему. Вы войдете в систему под этим

пользователем с некоторым паролем, многократного использования и затем, keysh

спросит у Вас ответ на S/Key-вызов, перед тем, как предоставить Вам нормальную

оболочку.

Вы должны добавить

access:x:100:100:Access Account:/tmp:/usr/local/bin/keysh

в конец файла /etc/passwd и

access:NP:6445::::::

в конец файла /etc/shadow. Затем, используйте команду passwd access, для того, чтобы

установить пароль пользователю access. Пароль, который Вы введете, не обязательно

делать слишком заумным, так как Вы будете полагаться на keysh, для обеспечения

защиты этого пользователя.

Так как /usr/local/bin/keysh не является стандартным, Вам придетсясоздать файл /etc/shells

со следующими строками:

/sbin/sh/usr/local/bin/keysh

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

смогут получить доступ к машине.

Теперь, создайте файл /etc/skeykeys и поставьте на него права 600 пользователю root:

touch /etc/skeykeyschmod 600 /etc/skeykeys

chown root /etc/skeykeys

chgrp root /etc/skeykeys

Используйте команду keyinit access, чтобы инициалиализировать S/Key для

пользователя access. Теперь, Вы закончили установку пакета S/Key для этого

пользователя.

Сейчас можно позволить пользователю access использовть команду keysu, чтобы стать

администратором. Сначала измените строку для группы root в файле /etc/group:

root::0:root,access

Только те пользователи, которые содержатся в этой строке, могут стать

администраторами используя keysu. Теперь, Вы должны запустить keyinit root, чтобы

инициализировать S/Key для администратора. Мы рекомендуем использовать другой

пароль, нежели был у пользователя access.

С этого момента, Вы можете удалить /bin/su, чтобы пользователи были вынуждены

использовать keysu. К сожалению, много различных скриптов используют /bin/su, чтобы

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

500 /bin/su, чтобы только администратор мог запускать эту программу.

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

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

администратору отдельный вход с различным ключами S/Key, чтобы Вы получили

больше возможностей для контроля их действий. Обратная сторона этого подхода состоит

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

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

должы решить, что же имеет больший смысл для вашей организации.

5.7) Конфигурирование сервиса wu-ftp

Конфигурирование wu-ftpd довольно сложная задача, даже для экспертов. Когда Вы

компилировали wu-ftpd, Вы должны были определить каталог, где програма будет искать

файлы конфигурации. Этот каталог будет содержать директорию pid и три файла.

ftpconversions должен быть пустым, но должен существовать. ftpusers должен

содержать список пользователей, которым НЕ разрешен доступ в систему посредством

ftp. Пользователь root обязательно должен быть в этом списке! Файл должен содержать

всех пользователей из файла /etc/passwd - позднее мы добавим пользователя, которому

разрешен доступ по ftp.

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

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

анонимный доступ по ftp в вашу систему, но хотите, чтобы некоторые пользователи

могли записывать свои файлы на сервер.

class users real 172.16.3.*

log commands real

log transfers real inbound,outbound

Таким образом, мы позволяем пользователям зайти по ftp с любого компьютера сети

172.16.3.0 и ниоткуда больше (это уже не обязательно, так как Вы уже используете tcpd,

но эшелонированная оборона никогда не помешает). Все команды и передачи файлов

будут записаны в файле, который Вы определили при компиляции программы (как мы

рекомендовали, он должен быть в каталоге /var).

Конфигурирование анонимного ftp-доступа выходит за рамки данного справочника, но

будьте очень осторожны,так как слишком просто сделать ошибку и отдать доступ всем

подряд в вашу систему. Перечитайте документацию, которая поставлялась вместе с wu-

ftpd и просмотрите другие докуметы, в которых даются рекомендации по установке

анонимного ftp.

5.8) Ограничение доступа к файлам и файловым системам

Загрузите и измените переустановленные права. Программа в этом пакете убирает все

небезопасные права группам на некоторые каталоги. Этот скрипт был переделан для

запуска на системах Solaris 2.5.

Один из путей обломить хакеров - запретить им использование setuid-программ. Меры,

которые Вы уже приняли, делают почти невозможным запуск несанкционированных

setuid-программ на Вашем сервере, но кусочек паранои Вам никогда не помешает :)

Используйте параметр nosuid в файле /etc/vfstab для того, чтобы предотвратить

возможность выполнения на некоторых томах UFS вашей системы:

/proc - /proc proc - no -fd -

/dev/fd fd - no -

swap - /tmp tmpfs - yes -

/dev/dsk/c0t3d0s1 - - swap - no -

/dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0 / ufs 1 no remount,nosuid

/dev/dsk/c0t3d0s4 /dev/rdsk/c0t3d0s4 /usr ufs 1 no ro

/dev/dsk/c0t3d0s5 /dev/rdsk/c0t3d0s5 /var ufs 1 no nosuid

/dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6 /local ufs 2 yes nosuid

Обратите внимание, что /usr содержит некоторые setuid-программы (еще и те, которые

принадлежат S/Key в /usr/local/bin), так что мы монтируем этот том только для чтения

вместо nosuid. Корневая файловая система монтируется при загрузке boot-PROM'ом, так

что она должна быть перемонтирована повторно установки параметра nosuid.

Вы не должны применить директиву nosuid к специальным файловым системам.

Обратите внимание, что тип файловых систем TMPFS (как для /tmp) - автоматически

устанавливается как nosuid в последних версиях Solaris.

5.9) Проверка конфигурации

Перезагрузите вашу систему, в последний раз и подключите ее в сеть. Проверьте, что

следующие пункты выполнены:

 Вы можете зайти через telnet и ftp на ваш сервер с тех компьютеров, которые

перечислены в конфигурации tcpd.

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

отказом в доступе и посылкой уведомления по электронной почте по

соответствующему адресу.

 Вы должны суметь войти в систему через telnet и ftp как пользователь access, но не

как root или любой другой пользователь.

 Пользователь access способен запустить /usr/local/bin/keysu, чтобы стать

администратором.

 ps -ef должна выдать очень маленькое количество процессов; в частности,

sendmail и процессы NFS не должны быть запущены.

 touch /usr/FOO не должна сработать с появлением об ошибке: "the filesystem is

read-only".

 Как пользователь root, скопируйте программу ps в корневой каталог / и

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

доступе, при попытке выполнить /ps -ef. После чего, удалите /ps.

Поздравляем! Теперь Ваш сервер надежно защищен!

5.10) Дополнительные предложения

Имеется ряд свободно доступных замен для общих системных программ, которые

защищены значительно лучше, чем версии, поставляемые с системой Solaris. Рассмотрите

замену sendmail-а последней версией. Замените библиотеку bind. Замените syslog и

crontab (проверьте свой локальный Archie-сервер).

Ваши файлы записи событий могут оказаться бесполезными если на сервере стоит

неправильное время.Рассмотрите выполнение службы XNTP, чтобы часы системы были

всегда в норме и синхронизовывались с точными источниками из Internet и с другими

машинами вашей сети. Если кто-то взломал Вашу сеть, то Вам придется побегать по всем

файлам регстрации событий по всей сети, в таком случае, очень желательно, чтобы на

всех машинах время шло синхронно.

Прежде чем ваша система начнет свою жизнь в сети, загрузите tripwire и сделайте базу

данных MD5 контрольных сумм для всех файлов сервера. Поместите эту базу данных на

сменные устройства (лента или гибкий диск) так, чтобы никто, даже вломившись на Ваш

сервер, не смог изменить эти данные. Иногда выполняйте tripwire, для полной

уверенности, что никто не подменил Ваши файлы.

Рассмотрите сбор информации о запускаемых процессах, чтобы иметь запись всех

выполняемых порграмм. Эффективность Вашей системы может понизиться (от 10 до 20

%) в том случае, если Вы включите этот учет процессов. См. man acct для получения

дополнительной информации.

Регулярно изменяйте ваши S/Key-ключи (каждые 30 дней, если Вы сможете выдержать

это) и выбирайте хорошие пароли (использоуйте не алфавитно-цифровые символы и

длинные слова). Изменяйте эти ключи с консоли или используйте keyinit -s, для

изменения их через сеть. Не используйте одинаковые пароли для обоих пользователей root

и account.

6) Благодарности

Следующие люди внесли свой вклад в содержание этого FAQ-а:

 Casper Dik (везде)

 Hal Pomeranz (в основном раздел 5)

 Michele Crabb (разделы 1 и 2)

 Dan Stromberg (информация о программах проверки паролей)

 Darren J Moffat (Дополнения по Solaris 2.6 и 7)

 Jan Koum (Q 2.30)

Об авторе

Питер Баер Гальвин - Главный Технолог в Corporate Technologies, системный интегратор,

а так же VAR. Перед этим, Питер был Системным Администратором в Отделе

Информатизации Университета Brown. Он писал статьи для журналов Byte и некоторых

других. Так же перед этим писал статьи в секции "Pete's Wicked World", электронного

журнала SunWorld. Питер - соавтор книги Operating Systems Concepts. Как консультант и

преподаватель, Питер создал учебники по защите и системному администрированию, а

так же выступал на многих конференциях. Вы можете связяться с ним по адресу

peter.galvin@sunworld.com.