Укрепление (hardening) сервера
9.5.3 Определение доступа к доверенному коммуникационному пути
Trusted Computing Base (Доверенная вычислительная база, TCB) является частью системы, которая отвечает за проведение в жизнь общесистемных политик информационной безопасности. Установкой и использованием TCB можно определить доступ пользователя к доверенному коммуникационному пути (trusted communication path), который предполагает защищенную коммуникацию между пользователями и TCB.
Функциональные возможности TCB могут быть включены только во время установки системы. Для того чтобы установить TCB на уже готовую машину, нужно выполнить установку в режиме "preservation". Включение TCB дает возможность доступа к доверенной оболочке (trusted shell), к доверенным процессам и к ключу безопасности внимание (Secure Attention Key, SAK).
Поскольку каждое устройство является частью TCB, каждый файл каталога /dev отслеживается системой TCB. Кроме того, TCB автоматически следит за более чем 600 дополнительными файлами, сохраняя критическую информацию об этих файлах в /etc/security/syschk.cfg. Если TCB установлена, сразу же после установки с этого файла следует снять резервную копию на съемный носитель, такой, как лента, CD или диск, и на носитель, хранимый в безопасном месте.
9.5.4 Обработка особых ситуаций
В процессе укрепления своих систем администраторы систем AIX могут столкнуться со множеством различных ситуаций. Данный раздел как раз и проливает свет на подобные особые ситуации.
Особые разрешения
Если для каких-либо пользователей и групп устанавливаются особые разрешения, все эти выделенные особые разрешения следует задокументировать и наметить шаги для согласования с вопросами безопасности. Если особые разрешения не задокументированы, другие не будут в курсе этих особых ситуаций и могут пренебречь теми шагами, которые должны быть предприняты.
Особые привилегии
При установке нового программного обеспечения, такого, как сервер Domino или сервер DB2, могут возникнуть вопросы в связи с созданием новых учетных записей и выделением особых привилегий для них. Отдавайте себе отчет по всем новым ID, их привилегиям и правам собственности на файлы и папки, чтобы потом не оказалось непреднамеренного обмана политики безопасности организации.
Особые пароли
Пароль на включение питания. Данный пароль, если установлен, препятствует кому бы то ни было перезагружать сервер простым его выключением из сети питания и затем включением вновь. Если в CD-ROM-привод вставлен загрузочный CD-носитель, система перезагружается, а затем уже будет грузиться с CD и, следовательно, не станет придерживаться своей безопасной конфигурации, что приводит к нарушению режима безопасности. Если система перезагружается и если пароль на включение питания установлен, во время цикла перезагрузки система потребует ввести этот пароль. Это может повлиять на действующие соглашения об уровне сервиса (Service Level Agreements, SLAs), так как может быть определенная задержка по времени между моментом, когда сервер перезагружается до точки запроса пароля на включение питания, и моментом, когда ему будет позволено продолжать свою загрузочную последовательность после того, как пароль был введен. В идеале первостепенность будет установлена политикой безопасности организации (безопасность против соглашений по предоставлению услуг).
Пароль супервизора. Данный пароль не дает неавторизованному пользователю загрузиться в режим поддержки при помощи загрузочного носителя (загрузочный CD, mksysb лента/CD). Загрузка с подобного носителя предоставляет полный доступ к файлам и каталогам абсолютно без ограничений в плане безопасности. Пароль супервизора закрывает систему, и, если этот пароль утерян, понадобится помощь обслуживающего персонала IBM для того, чтобы отпереть ее.
Пароль root. Это пароль суперпользователя, который время от времени может быть нужен. Важно отдавать себе отчет в том, когда действительно может понадобиться учетная запись root, и на такие случаи в реализации системы безопасности организации должны присутствовать планы.
Слабые места системы безопасности
Каждому хорошему системному администратору AIX следует быть осведомленным о тех системах в ИТ-инфраструктуре организации, в которых могут иметься слабые места для общей системы безопасности. Если предполагаемый взломщик взломает одну из машин, находящихся внутри сети организации, он может получить доступ и к другим машинам посредством разрешений, установленных между данной машиной и другими системами в сети.
Некоторые из предполагаемых взломщиков сканируют сети на наличие определенного типа машин и определенных версий операционных систем с целью найти какую-нибудь одну такую, которую можно было бы взломать, а затем они могут использовать эту точку входа для получения доступа ко всем машинам в сети.
9.5.5 Разрешение системного аудита
Пользователи регулярно производят различные системные действия, за которыми не мешало бы наблюдать более тщательно. Установкой системного аудита дается возможность записывать касающуюся безопасности информацию, которая затем может быть проанализирована на факт наличия потенциальных и фактических нарушений системной политики безопасности.
Предопределенные события аудита можно найти в файле /etc/security/audit/events. Для генерации регулярных отчетов при помощи возможностей службы cron можно установить автоматическое ведение аудита.
9.5.6 Слежение за файлами, каталогами и программами
Наше обсуждение укрепления было бы неполным без рассмотрения механизмов, которые можно использовать для наблюдения за доступом к файлам, каталогам и исполняемым программам.
Удаление устаревших файлов
Время от времени появляется необходимость в удалении нежелательных и ненужных файлов с сервера AIX.
AIX предоставляет системному администратору команду skulker, которая может автоматически отследить и удалить устаревшие файлы. Кандидатами на обработку данным средством являются файлы, расположенные в каталоге /tmp, исполняемые файлы a.out, файлы core и ed.hup. Для запуска команды skulker введите в командную строку следующее:
# skulker -p
Вы можете автоматизировать команду skulker, заставив cron регулярно выполнять данную задачу.
Удаление файлов, не имеющих владельца
Когда ID пользователя удаляется, файлы этого пользователя больше не имеют владельца, приписанного к ним. Для нахождения файлов, не имеющих владельца, используйте команду find так, как показано ниже:
# find / -nouser -ls
После идентификации файлов без владельца определите, нужны ли еще эти файлы. Если нужны, их следует приписать другому пользователю. В противном случае эти файлы можно удалить из системы.
Управление неавторизованным удаленным доступом к хосту
Для получения доступа к системе некоторые программы используют файл .rhosts. В некоторых случаях доступ может быть предоставлен и неавторизованным пользователям. Для избежания подобной ситуации файл .rhosts следует удалить с сервера AIX.
Для кластеров HACMP файлы .rhosts нужны16В HACMP 5.x этот файл больше не нужен.. В таких конфигурациях вместо удаления этим файлам следует установить разрешения 600 и назначить права собственности root.system.
Для нахождения файлов .rhosts запустите следующую команду:
# find / -name .rhosts -ls
Слежение за исполняемыми файлами
Для слежения за активностью исполняемых файлов особой важности требуется хорошее понимание того, как эти файлы используются. Исполняемые файлы, за которыми требуется наблюдение, – это те файлы, которые принадлежат пользователю root и у которых установлен хотя бы один из битов SUID и SGID.
После тщательного наблюдения за этими файлами во время нормальной работы системы можно составить отчет, в который будет входить список файлов, которые работают нормально. Затем этот отчет можно сверить с последующими отчетами, что выявит все новые файлы, атрибуты которых были выставлены без ведома системного администратора AIX. Для создания шаблонного отчета воспользуйтесь следующими командами:
# find / -perm -4000 -user 0 -ls # find / -perm -2000 -user 0 -ls
Управление задачами cron и at
Для управления задачами cron и at проделайте следующее. Убедитесь в том, что единственным пользователем, упоминающимся в файлах cron.allow и at.allow, является root.
Из каталога /var/adm/cron удалите cron.deny и at.deny.
Убедитесь в том, что задачи cron и at принадлежат пользователю и могут выполняться только им root.
9.5.7 Управление тем, что относится к X11 и CDE
В этом разделе рассказывается о потенциальных "дырах" безопасности, пришедших вместе с X-сервером X11 и с окружением CDE (Common Desktop Environment).
Удаление файла /etc/rc.dt
Хотя запуск графического пользовательского интерфейса CDE и удобен для пользователей, с ним связаны некоторые проблемы для безопасности. По этой причине CDE не следует запускать на серверах, для которых требуется высокий уровень безопасности.
Самым лучшим решением было бы вообще избегать установки файловых наборов CDE (dt). Если же данные наборы все-таки были установлены на сервер, следует рассмотреть вопрос их удаления, особенно сценария /etc/rc.dt, который запускает CDE.
Предотвращение неавторизованного слежения за удаленным X-сервером
Важный вопрос безопасности, связанный с сервером X11, – это неавторизованное тихое слежение за удаленным сервером. Для слежения за работой X-сервера могут быть использованы команды xwd и xwud, поскольку они обладают возможностью перехватывать нажатия клавиш, что может раскрыть пароли и другие важные данные. Для решения данной проблемы либо просто удалите эти исполняемые файлы, если они не нужны для текущей конфигурации сервера, либо разрешите доступ к этим командам только пользователю root.
Команды xwd и xwud можно найти в файловом наборе X11.apps.clients.
Если команды xwd и xwud нужно оставить, подумайте об использовании OpenSSH или MIT Magic Cookies. Эти приложения сторонних производителей помогут предотвратить риск, связанный с запуском команд xwd и xwud.
Разрешение и запрещение контроля доступа
X-сервер дает возможность удаленным хостам использовать команду xhost+ для соединения с сервером AIX. Убедитесь, что вместе с командой xhost+ задано и имя хоста, потому что иначе контроль доступа для данного X-сервера будет запрещен. Это разрешит предоставление доступа к конкретным хостам, которые облегчат слежение за потенциальными атаками на X-сервер. Для предоставления доступа к конкретным хостам запустите команду xhost следующим образом:
# xhost + имя хоста
Запрещение пользовательских разрешений для запуска команды xhost
Еще один способ гарантировать то, что команда xhost используется должным образом, – это ограничить выполнение этой команды только при наличии полномочий суперпользователя. Для этого воспользуйтесь командой chmod и измените разрешения файла /usr/bin/X11/xhost на 744, как показано ниже:
# chmod 744/usr/bin/X11/xhost
Убедитесь, что вместе с командой xhost задано имя хоста. Это разрешит предоставление доступа к конкретным хостам, которые упрощают слежение за потенциальными атаками на X-сервер.
Замечание. Если имя хоста не задано, доступ будет предоставлен всем хостам.
9.5.8 Запрещение ненужных служб
В этом разделе обсуждаются открытые коммуникационные порты, как их можно идентифицировать и как закрыть.
Определение сетевых служб с открытыми коммуникационными портами
Клиент-серверные приложения открывают на сервере коммуникационные порты, позволяя приложениям слушать входящие запросы клиентов.
Поскольку открытые порты – потенциальные кандидаты для атаки, определите, какие приложения открыли порты; но совсем не обязательно закрывать все порты, которые открыты. Это упражнение полезно уже тем, что дает системным администраторам возможность понять, что системы являются доступными любому, у кого есть доступ к Интернету.
Для определения того, какие порты открыты, проделайте следующее.
Идентифицируйте службы при помощи команды netstat:
# netstat -af inet
Результат работы данной команды достаточно ясен для интерпретирования. Последний столбец вывода команды netstat обозначает состояние каждой службы.
После определения того, какие службы в настоящий момент слушают, откройте файл /etc/services и проверьте его при помощи служб центра по присвоению номеров Интернета (Internet Assigned Numbers Authority, IANA) для постановки в соответствие службы номеру порта внутри операционной системы.
Закройте ненужные порты удалением запущенных служб.
Составление списка открытых файлов
Полезно определить TCP-сокеты, которые находятся в состоянии LISTEN, и ненагруженные UDP-сокеты, которые ожидают получения данных.
Для этой цели воспользуйтесь командой lsof, которая является вариантом команды netstat -af. Команда lsof входит в AIX 5.1 и находится на диске "AIX Toolbox for Linux Applications CD".
Например, чтобы вывести на экран TCP-сокеты, находящиеся в состоянии LISTEN, и UDP-сокеты, находящиеся в состоянии IDLE, запустите команду lsof следующим образом:
# lsof -i | egrep "COMMAND|LISTEN|UDP"
После определения ID процесса можно получить более подробную информацию о самой программе, выполнив следующую команду:
" # ps -fp PID#"
Вывод будет содержать путь к имени команды, который можно использовать для доступа к man-странице данной программы.
9.6 Резюме
В этой лекции мы рассмотрели инструменты и техники, используемые для защиты ИТсистем и предотвращения атак.
Мы дали подсказки по укреплению операционной системы, рассказали об инструментах и программах, используемых для создания сплошной защиты, а также о методах профессионалов безопасности по сбору сведений в тех случаях, когда взломщики пробили внешнюю защиту.
Предоставленная нами информация может принести пользу организации любого размера, от маленькой домашней фирмы до очень большой организации с офисами по всему миру.
Хотя самое важное, что нужно запомнить, – это то, что нет 100 % надежных ИТ-систем в течение 100 % времени.
Таким образом, важно еще понять, что, как только система – и ее безопасность – на месте, начинается следующая фаза работы по обеспечению безопасности. То есть время наблюдать за ИТ-системой и определять, какие еще улучшения могут быть внесены в систему для продолжения и совершенствования ее безопасности, а также для поддержания целостности и конфиденциальности содержащейся в ней информации. Тогда и только тогда будет иметь место надлежащая и адекватная безопасность.