Отчеты по безопасности в AIX

Защита системы при помощи ежемесячных отчетов по безопасности

Отчеты по безопасности IBM® AIX® должны отражать текущее состояние модели защиты вашей системы и могут быть переданы на рассмотрение ответственным лицам или аудиторам для оценки состояния защищенности системы AIX. В этой статье я расскажу, информацию о каких объектах необходимо отслеживать, и почему.

Дэвид Тенсли, системный администратор, Ace Europe

фото Дэвида ТенслиДэвид Тенсли (David Tansley) — один из внештатных авторов IBM developerWorks. У него более 15 лет опыта администрирования UNIX-систем, а последние 8 лет он специализируется на AIX. В сферу его личных интересов входят бадминтон и Формула 1, но наибольшее удовольствие он получает, путешествуя на своём мотоцикле вместе с женой.



03.07.2013

Создание отчетов о состоянии модели безопасности позволяет системным администраторам эффективнее контролировать и защищать серверы AIX, а также гарантирует то, что система защищена в соответствии с предъявляемыми требованиями. Также эти отчеты дают наглядное представление о стандартной политике безопасности, принятой на текущий момент. Прежде чем перейти к рассмотрению того, что должно быть включено в ежемесячные отчеты по безопасности и результатам аудита, я расскажу, в каком виде эти отчеты могут быть представлены. Хотя я буду рассказывать об отчете по безопасности, помните о том, что данные этого отчета будут собраны с нескольких серверов AIX, и поэтому информацию следует хранить так, чтобы она была точной, актуальной и полезной; отчет должен быть разбит на разделы, заголовки которых должны ясно отражать их содержимое. На ваше усмотрение вы можете либо создавать отдельные отчеты для каждого сервера, либо помещать все данные в один отчет. Хотя я использовал оба подхода, я все-таки предпочитаю вариант с созданием одного общего отчета. Подумайте над возможностью представления информации в HTML-формате с использованием тегов и заголовков, чтобы при щелчке по названию раздела можно было сразу переходить к его содержимому. Код HTML-отчета можно поместить в тело электронного письма либо выводить непосредственно на Web-странице. Какой из этих вариантов использовать – решать вам, исходя из принятых в вашей организации стандартов.

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

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

  • Протокол SSH
  • Инструмент TCP wrappers
  • Служба аудита AIX
  • Команда Sudo

Информацию о каких объектах должен содержать отчет?

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

  • Уведомления о безопасности IBM.
  • Отчет о политике паролей (параметры и срок действия).
  • Отчет о назначенных правах доступа к файлам для пользователей и групп (отличных от встроенных пользователей и групп IBM).
  • Список групп пользователей в соответствии с политикой приложений.
  • Заблокированные учетные записи владельцев системных процессов, например, lpd или bin.
  • Список учетных записей, заблокированных по истечении заданного количества дней в связи с неактивностью.
  • Списки всех новых или удаленных пользователей.
  • Списки всех новых или удаленных групп.
  • Списки пользователей, которым были предоставлены либо отозваны привилегии на выполнение команды su.
  • Информация о том, какие учетные записи являются членами каких групп.
  • Информация о том, кому разрешен доступ к выполнению команды su (это могут быть пользователь root и владельцы приложений).
  • Атрибуты входа в систему, для которых параметр admin установлен в true.
  • Информация о том, запрещен ли удаленный доступ от имени пользователя root.
  • Списки пользователей, которым разрешено использовать протоколы File Transfer Protocol (FTP), Secure Shell (SSH) и Secure Copy Protocol (SCP) для доступа к серверу AIX.
  • Информация о том, отключена ли служба rexec в файле /etc/ineted.conf.
  • Информация обо всех найденных файлах rhosts.

Теперь рассмотрим все эти объекты более подробно.

Уведомления

Уведомления о безопасности IBM содержат сведения об уязвимостях и рассылаются корпорацией IBM в виде подробных электронных писем. Такие письма могут содержать предупреждения о возможности компрометации процесса или службы при определенных условиях, исправления ПО или решения каких-либо известных проблем. Получая такие уведомления, вы сами решаете, касается ли вас обозначенная проблема и следует ли предпринимать какие-либо действия по ее устранению. Эти сообщения электронной почты следует сохранять в таблице или базе данных и таким образом вести их историю (когда было получено уведомление и какие действия были предприняты в связи с этим). При получении уведомления следует сделать соответствующую запись в отчете по безопасности.

Политика паролей

Использование хорошей политики паролей (под этим я подразумеваю срок действия и правила составления паролей) является первоочередной задачей. Используемая в рабочем окружении политика паролей должна соответствовать жестким стандартам. В некоторых случаях можно использовать политики паролей двух типов. Например, срок действия паролей обычных пользователей может составлять определенное количество дней (скажем, 35). Однако применение такой политики к владельцам приложений или пакетных файлов может создать проблемы. Естественно, что такой пароль не должен меняться среди ночи во время выполнения пакетного файла, поэтому срок его действия должен быть неограниченным. Тем не менее, правила составления пароля (например, количество повторяющихся символов и минимальная длина пароля) должны быть одинаковыми для всех пользователей. Если вы используете, заданные в директории /etc/security, то следует сравнить определенные по умолчанию строфы на предмет соответствия правилам применяемой политики и выявить все возможные расхождения. При наличии известных вам исключений необходимо составить и включать в отчет соответствующие списки. При использовании сетевой аутентификации (например, с помощью LDAP или Kerberos) следует также проанализировать все расширенные атрибуты.

В листинге 1 продемонстрирован метод, в котором можно сравнить и просмотреть отчет об атрибутах учетных записей. Файл шаблона, содержащий атрибуты стандартной политики, сравнивается со строфами атрибутов по умолчанию из файла /etc/security/user удаленного сервера AIX. При этом сразу можно обнаружить любые несоответствия. Учетные записи пользователей, исключенные из проверки, также отображаются.

Листинг 1. Атрибуты учетной записи
Standard attributes: 	   Current attributes:	

admin  =	 	         admin 	=	 false	
login  =	 true            login 	=	 true	
su 	   =	 true	         su 	    =	 true	
daemon 	=	 true	 	 daemon 	=	 true	
rlogin 	=	 true	 	 rlogin 	=	 true	
sugroups 	=	         sugroups	  =	 ALL	
admgroups 	=	 	 admgroups =	 	
ttys 	=	 		 ttys 	=	 ALL	
auth1 	=	 		 auth1 	=	 SYSTEM	
auth2 	=	 		 auth2 	=	 NONE	
umask 	=	 022	         umask 	=	 022	
expires 	=	 	 expires 	=	 0	
SYSTEM 	=	 		 SYSTEM 	=	 "compat"	
pwdwarntime 	= 5	 	 pwdwarntime 	=	 5	
account_locked  =	false    account_locked =	 false	
loginretries 	=  3	         loginretries 	=	 3	
histexpire 	= 26	 	 histexpire 	=	 26	
histsize 	  =	 15	 histsize 	=	 15	
minage 	  =	 1	 	 minage 	=	 1	
maxage 	  =	 5	 	 maxage 	=	 5	
maxexpired =	 -1	 	 maxexpired 	=	 -1	
minalpha 	=	 1	 minalpha 	=	 1	
minother 	=	 1	 minother 	=	 1	
minlen 	=	 8	 	 minlen 	=	 8	
mindiff 	=	 2	 mindiff 	=	 2	
maxrepeats =	 2	 	 maxrepeats =	 2	

Excluded users for this host: ukpen01dd
user1,user2,..

Какие идентификаторы set-uID есть в системе?

Приложения с идентификаторами set-uID, отличными от идентификаторов IBM, должны отслеживаться; вы должны иметь возможность узнать, когда было добавлено новое или изменено существующее приложение, сравнив информацию с информацией предыдущего запуска или log-файла. Все сделанные на заказ приложения с идентификаторами set-uID должны быть перечислены в отчете по безопасности. В дополнение к этому можно подумать об использовании команды fpm.

Членство в группах

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

Блокировка системных учетных записей

Учетные записи владельцев системных процессов (например, bin, lpd и т. д.) должны быть заблокированы. Фактически, нет никакой необходимости в том, чтобы эти учетные записи оставались незаблокированными, даже если атрибуты login/rlogin установлены в false. В отчете должны содержаться сведения обо всех нарушениях этого правила, а также о владельцах незаблокированных системных учетных записей.

Неактивные учетные записи

Необходимо связаться со всеми пользователями, не подключавшимися к серверу AIX в течение определенного периода времени, и выяснить, нужны ли им их учетные записи. По прошествии достаточно большого количеств дней (я предлагаю остановиться на 40 днях) такие учетные записи следует заблокировать (но не удалять). Если впоследствии пользователь направит запрос о разблокировке его учетной записи, одобренный лицом, ответственным за приложение, то его учетную запись всегда можно разблокировать. После более долгого периода неактивности учетную запись пользователя можно удалить. Тем не менее, здесь необходимо соблюдать осторожность, поскольку пользователь этой учетной записи может оказаться специалистом по поддержке приложения и подключаться к приложению через графический интерфейс. Таким образом, AIX не сможет обновить атрибуты входа в систему этого пользователя, и в таких случаях необходимо использовать какой-то другой механизм проверки или, возможно, поместить учетную запись в список исключений.

Работа с базой пользователей и групп

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

Команды su и sudo

Просмотрите файл sudoers и выясните, кто имеет доступ к команде su и входит в состав sugroups; привилегированный доступ гарантирует, что только управомоченные пользователи могут переключать полномочия пользователей. Часто случается так, что администраторы предоставляют пользователю временный доступ к команде su, а затем забывают отозвать его – таким образом, эта возможность остается у пользователя навсегда. Включая в отчет информацию о su группах, вы сможете быстро определить пользователей, которым следует запретить доступ к su. Как минимум, в отчет должна попадать информация о доступах к su для пользователя root, а также владельцев приложений и командных пакетных файлов.

Ниже показана типовая запись, позволяющая членам группы IBM DB2® (db2grp) получать привилеги пользователя экземпляра DB2 с именем db2inst1 на хосте ukpen01dd.

%db2grp  ukpen01dd  = NOPASSWD:/usr/bin/su - db2inst1

Административные учетные записи

Следует включать в отчет список всех пользователей, атрибуты учетных записей которых содержат параметр admin установленный в true. Обычно в этот список попадают системные учетные записи, в том числе root, daemon, bin, sys и lpd. Тем не менее, вы можете делегировать эти полномочия и другим пользователям, которые обязательно следует включить в список отчета.

Отключение удаленного входа в систему для пользователя root

На мой взгляд, пользователь root не должен иметь прав на удаленный вход в систему. Пользователь root должен входить в систему либо через процедуру su/sudo, либо только после прямого SSH-подключения к требуемому серверу. Такой подход существенно снижает возможности доступа для пользователя root. Возможность непосредственного входа в систему под учетной записью root следует оставить только для системной консоли или для консоли Hardware Management Console (HMC).

Доступ по протоколам FTP/SCP

Следует внимательно подумать о возможности предоставления доступа по протоколам SCP/FTP с удаленных серверов, поскольку пользователям, работающим над решением той или иной задачи, может потребоваться передавать файлы. После того, как будет составлен список пользователей, вы можете заполнить на его основе файл /etc/ssh/sshd.conf. Не забудьте также отредактировать и задать необходимые ограничения в файле ftpaccess.ctl, чтобы предоставить пользователям доступ по протоколу FTP. Можно также составить список пользователей, которым запрещен доступ по FTP, и внести эти сведения в файл /etc/ftpusers. Я придерживаюсь мнения, что пользователю root следует разрешить удаленный доступ только по протоколу SCP и только с выделенного сервера.

Небезопасные команды

Следует также проверить и выяснить, не раскомментирована ли строка службы rexec в файле /etc/inetd.conf. Я не хочу сейчас обсуждать причины этого, поскольку все они хорошо изложены в документации по безопасности Linux®, UNIX® и AIX. Единственную причину, по которой следует сегодня использовать эту службу, я вижу в возможных выгрузках сервера Network Installation Management (NIM), но включать ее следует только на время. Также следует с помощью команды find найти все файлы .rhosts в домашних директориях пользователей. При возникновении особой необходимости передать файл .rhosts через незащищенное подключение пользователь должен сообщить об этом, после чего следует предпринять все необходимые действия и переключить пользователя на использование SCP.

Проверка правильности файлов, содержащих списки паролей и групп

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


Как собрать все воедино

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

Для случаев, когда необходимо сравнивать пользователей, которым разрешено быть членами только определенных групп, я создал и использую файл шаблона. Этот шаблон можно распространять с центрального сервера перед запуском отчета. Причина заключается в том, что в течение месяца вы периодически будете обновлять файл на центральном сервере, внося в него новые группы и подгруппы, членами которых должен являться пользователь. Формат этого файла может совпадать с форматом файла /etc/group.

groupname1: usera,userb,..
groupname2: usera,userb,..

Дальше все очевидно – необходимо просто считать этот файл и сравнить его с существующими группами на сервере AIX, а информацию обо всех несовпадениях занести в отчет.


Заключение

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

Ресурсы

Научиться

Получить продукты и технологии

  • Оцените программные продукты IBM (EN) любым удобным для вас способом: загрузите ознакомительные версии, поработайте с ними в онлайновом режиме, используйте их в песочнице или облачной среде. Вы можете выбрать более чем из 100 ознакомительных версий программных продуктов IBM.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=AIX и UNIX
ArticleID=936544
ArticleTitle= Отчеты по безопасности в AIX
publish-date=07032013