Глава 22. Безопасность 967

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

Агенты работают в системах, которые подвергаются мониторингу, и сообщают ин­ формацию менеджеру. Они имеют маленькую зону обслуживания и оперируют неболь­ шим объемом привилегий. Большую часть конфигурации агент получает от менеджера. Соединение между сервером и агентом зашифровано и аутентифицировано. Для каждо­ го агента менеджер должен создать отдельный ключ аутентификации.

Система OSSEC классифицирует серьезность сигналов по уровням от 0 до 15; число 15 соответствует высшему уровню опасности.

46. Мандатное управление доступом

Мандатное управление доступом (Mandatory Access Control — MAC) представляет собой альтернативу традиционному механизму управления доступом в системе UNIX, который передает управление всеми разрешениями в руки администратора по безопас­ ности. В противоположность стандартной модели, описанной в главах 4 и 6, система MAC не позволяет пользователям модифицировать никакие разрешения, даже для своих собственных объектов.

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

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

Очевидно, что для реализации механизма MAC в операционных системах UNIX и Linux необходимо внести изменения в ядро. В рассмотренных нами системах семейства UNIX (Solaris, HP-UX и AIX) версии с внедренным механизмом MAC предоставляют­ ся за дополнительную плату. Эти версии называются Solaris Trusted Extensions (бывшая Trusted Solaris), HP-UX Security Containment и Trusted AIX соответственно.

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

47. Ssh: безопасная оболочка

Система SSH (Secure Shell) является безопасной заменой утилит rlogin, rcp и telnet. Она использует криптографическую аутентификацию для подтверждения личности пользователя и шифрует любые соединения между двумя компьютерами. Протокол, используемый системой SSH, разрабатывался для противодействия ряду воз­ можных атак. Он уже подробно описан в документах RFC4250-4256 и предложен орга­ низацией IETF в качестве стандарта.



Глава 22. Безопасность 973

Пакет SSH трансформировался из свободно распространяемой открытой системы (SSH1) в коммерческий продукт с немного иным (более надежным) протоколом (SSH2). К счастью, сообщество разработчиков открытых систем взяло ситуацию под контроль и выпустило пакет OpenSSH (поддерживаемый операционной системой OpenBSD), в ко­ тором реализованы оба протокола.

Основными компонентами пакета SSH являются серверный демон sshd и две ути­ литы пользовательского уровня: ssh предназначена для удаленной регистрации и scp — для копирования файлов. Среди остальных компонентов отметим команду ssh-keygen, генерирующую пары открытых ключей, и несколько утилит, необходимых для поддерж­ ки безопасных серверов X Windows.

Демон sshd способен аутентифицировать пользователей различными способами. Выбор остается за администратором.

• Метод А. Если имя удаленного компьютера, с которого регистрируется пользо­ ватель, указано в файле ~ / .rhosts, ~/.shosts, /etc/hosts.equiv или /etc/ shosts.equiv, то пользователь автоматически получает доступ в систему без про­ верки пароля. Подобная схема моделирует работу старого демона rlogind и, по нашему мнению, неприемлема для широкого применения.

• Метод Б. В дополнение к методу А, демон sshd может применять шифрование с открытым ключом для проверки адреса удаленного компьютера. Для того что­ бы это произошло, открытый ключ компьютера (генерируется при инсталляции пакета) должен находиться в файле /etc/ssh_known_hosts локального узла или в файле ~/.ssh/known_hosts пользователя. Если удаленный компьютер предо­ ставляет соответствующий секретный ключ (обычно хранится в файле /etc/ssh_ host_key, который недоступен для чтения рядовым пользователям), то пользова­ телю разрешается войти в систему без проверки пароля.

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

• Метод В. Демон sshd может применять шифрование с открытым ключом для идентификации самого пользователя. На этапе регистрации пользователь должен иметь доступ к файлу своего секретного ключа и предоставить пароль для его де­ шифровки. Ключ можно также создать без пароля, что является разумным реше­ нием для автоматической регистрации из удаленных систем.

•

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

Если вы решили использовать пару ключей, широко используйте команду ssh -v в процессе поиска ошибок.

Метод Г. Наконец, демон sshd может просто попросить пользователя ввести свой регистрационный пароль. Это напоминает утилиту telnet, за исключением того, что пароль и все данные, передаваемые в ходе сеанса, подвергаются шифрованию. Основной недостаток этого метода заключается в том, что пароли оказываются относительно слабыми (часто их длина ограничена 8 символами) и есть готовые программы (например, crack) для взлома таких паролей. Тем не менее этот метод, как правило, лучше всего подходит для повседневного использования.

974 Часть II. Работа в сети

Правила аутентификации задаются в файле /etc/sshd_config. Он уже заполнен разного рода конфигурационным, “мусором”, большую часть которого можно проигно­ рировать. Параметры, касающиеся аутентификации, перечислены в табл. 22.2.

Таблица 22.2. Параметры аутентификации, задаваемые в файле /etc/sshd_config

Параметр Метода По умол­ Назначение чанию

RhostsAuthentication A no Разрешает регистрацию через файлы ~/.shosts, /etc/shosts.equiv и т.п.

RhostsRSAAuthentication Б yes Разрешает регистрацию через файл ~/.shosts и другие, но также требует от компьютера предо­

ставить ключ

IgnoreRhosts А, Б no Задает игнорирование файлов ~/.rhosts и hosts.equivб

IgnoreRootRhosts А, Б noB

Запрещает аутентификацию пользователя root через файлы .rhosts и .shosts

RSAAuthentication В yes Разрешает аутентификацию пользователей по ме­ тоду шифрования с открытым ключом

PasswordAuthentication Г yes Разрешает использование обычных регистрацион­ ных паролей

а Методы аутентификации, к которым относится параметр.

6 Файлы ~/.shosts и shosts.equiv продолжают использоваться. в По умолчанию равен значению параметра ignoreRhosts.

Рекомендуемая нами конфигурация, в которой разрешаются методы В и Г, но не А и Б, такова.

RhostsAuthentication no

RhostsRSAAuthentication no

RSAAuthentication yes

PasswordAuthentication yes

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

PermitRootLogin no

Когда вы впервые устанавливаете соединение с новой системой посредством прото­ кола SSH, вам предложат принять открытый ключ для доступа к удаленному узлу (ко­ торый обычно генерируется в процессе инсталляции системы OpenSSH или сразу по­ сле этого). Настоящий параноик может проверить его вручную, но большинство из нас слепо доверяют этому ключу и сохраняют его в файле ~/.ssh/known_hosts. Протокол SSH больше не вспоминает о серверном ключе, пока он не изменится. К сожалению, не­ брежность пользователей по отношению к ключам новых систем делает их уязвимыми для атак злоумышленников, если ключ на самом деле был предоставлен системой хакера.

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

Утилита sshfp, доступная на сайте xelerance.com/software/sshfp, генериру­ ет записи SSHFP DNS, либо сканируя удаленный сервер, либо выполняя анализ ранее

Глава 22. Безопасность

975

принятого ключа из файла known_hosts. (Разумеется, в любом случае предполагает­ ся, что источник ключа известен и заслуживает доверия.) Использование этой утили­ ты не представляет трудностей: для генерирования ключа на основе сканирования сети применяется флаг -s, а для анализа файла known_hosts — флаг -k (по умолчанию). Например, следующая команда генерирует BIND-совместимую запись SSHFP для до­ мена solaris.booklab.atrust.com.

solaris$ sshfp solaris.booklab.atrust.com

solaris.booklab.atrust.com IN SSHFP 1 1 94a26278ee713a37f6a78110flad9bd... solaris.booklab.atrust.com IN SSHFP 2 1 7cf72d02e3d3fa947712bc56fd0e0a3i...

Добавьте эти записи в зонный файл домена (будьте осторожны с именами и коман­ дой $ORIGIN), перезагрузите домен и примените команду dig для верификации ключа.

solaris$ dig solaris.booklab.atrust.com. IN SSHFP | grep SSHFP

; <<>> DiG 9.5.1-P2 <<>> solaris.booklab.atrust.com. IN SSHFP

; solaris.booklab.atrust.com. IN SSHFP

solaris.booklab.atrust.com. 38400 IN SSHFP 1 1 94a26278ee713a37f6a78110f... solaris.booklab.atrust.com. 38400 IN SSHFP 2 1 7cf72d02e3d3fa947712bc56f...

По умолчанию утилита ssh не проверяет записи SSHFP. Для того чтобы заставить ее сделать это, добавьте параметр VerifyHostKeyDNS в файл конфигурации /etc/ssh/ ssh_config. Как и в большинстве случаев, связанных с использованием параметров клиента SSH, при первом обращении к системе вы можете также указать в командной строке аргумент -о "VerifyHostKeyDNS yes".

Утилита SSH имеет много вспомогательных функций, полезных для системных ад­ министраторов. Одна из них позволяет безопасно туннелировать соединения TCP с по­ мощью зашифрованного канала SSH, тем самым разрешая устанавливать соединения с небезопасными или защищенными брандмауэрами службами на удаленных сайтах. Эта функциональная возможность повсеместно предоставляется клиентам протокола и допу­ скает простое конфигурирование. На рис. 22.1 показано типичное использование тунне­ ля SSH. Этот рисунок должен помочь разобраться в принципах его функционирования.

Рис. 22.1. Туннель SSH для RDP-соединения

В этом сценарии удаленный пользователь желает установить RDP-соединение (уда­ ленная настольная система) с системой Windows, входящей в корпоративную сеть. Доступ к этому узлу или порту 3389 блокируется брандмауэром, но поскольку пользо­ ватель имеет доступ по протоколу SSH, он может маршрутизировать свое соединение через сервер SSH.

976 Часть II. Работа в сети

Для того чтобы установить соединение через сервер SSH, пользователь должен заре­ гистрироваться на удаленном сервере SSH с помощью команды ssh. В командной строке ssh он должен указать произвольный, но конкретный локальный порт (в данном случае 9989), на который утилита ssh должна перенаправить безопасный туннель к порту 3389 удаленной Windows-машины. (В стандартной реализации системы OpenSSH для этого до­ статочно задать аргумент -L локальный_порт :удаленный_узел :удаленный_порт.) Все порты источника в данном примере помечены как случайные, потому что выбор произвольного порта, с которым необходимо установить соединение, производится программой.

Для доступа к настольной Windows-машине пользователь должен открыть удаленного настольного клиента (в данном случае rdesktop) и ввести localhost:9989 как адрес серве­ ра, с которым он хочет установить соединение. Локальная утилита ssh получит соедине­ ние с портом 9989 и туннелирует трафик по существующему соединению через удаленный сервер sshd. В свою очередь, сервер sshd направляет соединение на узел Windows.

Разумеется, туннели, подобные этим, также могут оказаться преднамеренными или непреднамеренными лазейками. Системные администраторы должны использовать тун­ нели с осторожностью и обязаны следить за неавторизованным и неправильным ис­ пользованием этой возможности пользователями.

В последние годы протокол SSH стал целью регулярных атак на пароли методом перебора. Хакеры выполняют повторяющиеся попытки аутентификации как обычные пользователи, такие как root, joe или admin. Свидетельством таких атак являются реги­ страционные записи о сотнях и тысячах неудачных попыток зарегистрироваться. Для защиты от этих атак лучше всего отключить аутентификацию паролей. Пока, похоже, хакеры сосредоточились на порте 22, поэтому эффективной контрмерой является пере­ нос сервера SSH на другой порт. Однако история показывает, что защита по принципу “безопасность через неясность” (“security through obscurity”) редко бывает долговремен­ ной. Проверка на ваших системах может выявить слабые пароли, которые могут быть взломаны с помощью прямого перебора.