Аудит системы Linux в примерах

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

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

Эмили Ретлиф, разработчик программного обеспечения, IBM

Эмили Ретлиф (Emily Ratliff) занимается вопросами безопасности Linux в IBM Linux Technology Center. Среди других проектов она занимается многократными проверками на соответствие Common Criteria, Trusted Computing, Kerberos Enterprise Identity Mapping. Конечная цель Эмили состоит в том, чтобы защитить оставленное без присмотра рабочее место от случайных (и удивительно успешных) нападений ребенка.



26.06.2007

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

Требования системного аудита

Требования безопасности, которые вы проверяете в ходе текущего аудита системы, должны быть такими же, как требования и основы безопасности, определенные для инсталляции системы. Состоящая из трех частей серия статей от developerWorks "Обеспечение безопасности в Linux (Securing Linux)" дает представление о том, как установить достаточно безопасную Linux-систему. Систематический аудит системы также поможет усовершенствовать политику безопасности, используемую для инсталляций на новых машинах, поскольку это поможет организовать обратную связь с фактически используемыми подсистемами.

Первые средства для удовлетворения этим требованиям —системный аудит и обнаружение вторжения на хост. Эта статья сфокусирована на системном аудите. Системы обнаружения вторжения на хост, такие как tripwire, AIDE и Samhain, отслеживают время произведенных в файловой системе изменений и, следовательно, являются важными средствами, позволяющими гарантировать, что система сохраняет известное состояние. В Linux Gazette есть интересная статья, "Конструктивная паранойя" ("Constructive Paranoia"), об использовании этих средств (см. ссылку ниже в разделе Ресурсы).

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

  • Обоснованность suid/sgid для исполняемых файлов в системе, и почему suid/sgid для них установлены
  • Проверять, не содержит ли файловая система с полностью открытыми для записи каталогами (/tmp и /var/tmp) файлов suid/sgid
  • Открытые порты и воздействие на незащищенные брандмауэром порты

Для чего нужны все эти suid-файлы?

Идентификация suid и sgid файлов на вашей системе — и отключение ненужных — одно из фундаментальных правил инсталляции безопасной системы. Это задача является настолько распространенной, что страница руководства для команды find выводит для этого в своих примерах список параметров. Листинг 1 — скрипт, который выполняет типичную команду find, а также помогает ответить на вопрос, что делает файл suid и какому пакету он принадлежит, чтобы помочь администратору выявить такие файлы и принять решение, должны ли они оставаться в системе или должны быть удалены. (Вы можете загрузить код для Листингов 1, 3 и 4 из zip-файла из расположенного ниже в этой статье раздела Загрузить.)

Листинг 1. Примеры вывода файлов suid/sgid (сокращенный вариант)
[root@localhost hpc]# ./find_setuids.pl /
04755 root /usr/X11R6/bin/cardinfo
       cardinfo - PCMCIA card monitor and control utility for X
pcmcia-cardinfo-3.2.7-107.3

04755 root /usr/bin/opiepasswd
       opiepasswd -  Change or set a user's password for the
       OPIE authentication system.
Opie-2.4-544.1

04755 root /usr/bin/opiesu
       opiesu  -  Replacement  su(1)  program that uses OPIE challenges
opie-2.4-544.1

04755 root /usr/bin/sudo
       sudo - execute a command as another user
sudo-1.6.7p5-117.4

Какие файловые системы содержат полностью открытые для записи каталоги?

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

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

Сокращенный пример вывода каталогов, полностью открытых для записи:
/ Содержит и suid/sgid-файлы, и полностью открытые для записи каталоги.


Какие порты сети система использует и для какой цели?

Есть несколько способов определить, какие порты используются в вашей системе. Наиболее полезные инструменты — nmap, netstat и lsof.

  • Nmap— чрезвычайно гибкий инструмент, который может активировать или деактивировать сканирование удаленных (и локальных) систем.
  • Netstat показывает информацию о сети локальной системы. По умолчанию показывает открытые соединения.
  • Lsof показывает список открытых в системе файлов. Может использоваться для получения информации об использовании порта, поскольку показывает информацию о сетевых сокетах.

Курт Сейфрид (Kurt Seifried) поддерживает список из 8,457 широко используемых портов. (Ссылку на его список портов см. ниже в разделе Ресурсы.) Вы можете использовать эти данные, чтобы выяснить, для чего используется порт и как воздействовало бы отключение этого порта в брандмауэре. Он содержит информацию о портах, которые обычно используются для засылки троянов и руткитов (наборов для получения прав root); например, 31337 обычно использует Back Orifice, а 12345, 12346 и 20034 — netbus.

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

Листинг 2. Пример вывода port_scan.sh:
[root@localhost hpc]# ./port_scan.sh
  please wait...
PORT              SERVICE         LINK
22                sshd
http://www.seifried.org/security/ports/0/22.html
25                sendmail
http://www.seifried.org/security/ports/0/25.html
123               ntpd
http://www.seifried.org/security/ports/0/123.html
631               cupsd
http://www.seifried.org/security/ports/0/631.html
46336 <-> 22      ssh             **

В Листинге 2 порты с маленькими номерами (<1024) показывают демоны, запущенные в системе, которые принимают входящее сообщение, если включен брандмауэр. Порт с большим номером 46336 показывает исходящее ssh-соединение и порт (22) на другом конце соединения. Это означает, что блокировка исходящего сообщения на временно открытых портах прервет выполнение широко используемых клиентских программ, например, ssh. Более подробную информацию о воздействиях настройки брандмауэра на портах с большими номерами см. в списке портов, составленном Куртом, в разделе Ресурсы.

Эти скрипты и инструменты показывают используемые в какой-то момент времени порты. Аудит системы может использоваться для выявления использовавшихся портов (во время аудита log-файлов), даже если они в настоящее время не используются. Добавление к /etc/audit.rules следующего правила проверки будет регистрировать запросы на подключение.

-a entry,always -S socketcall -F a0=2

Параметр -a entry,always показывает, что правило всегда должно вызываться в начале выполнения системного вызова. -S socketcall показывает, что это правило проверки для системного вызова socketcall. Системный вызов socketcall мультиплексируется на архитектуре i386, поэтому -F a0=2 требует ограничить записи проверки, сгенерированные только для подключения.

Другие архитектуры управляют системными вызовами для подключения иначе, поэтому чтобы обращаться с архитектурой, отличной от i386, эти команды и скрипты необходимо будет немного изменить. Результаты проверки записываются как составные записи проверки, которые связываются между собой общим последовательным числом. ausearch сопоставляет родственные записи при помощи последовательного числа и представляет их как группу. Флаг -i указывает, что численные значения, обозначающие, например, saddr (IP-адрес) и uid (имя пользователя), должны быть переведены в удобный для чтения текст, если это возможно.

Листинг 3. Сокращенный вывод ausearch
# ausearch -i -sc socketcall
Abbreviated example output
----
type=SOCKETCALL msg=audit(11/20/2006 11:28:43.844:10) : nargs=3 a0=0
a1=b8004004 a2=10
type=SOCKADDR msg=audit(11/20/2006 11:28:43.844:10) : saddr=inet
host:127.0.0.1 serv:631
type=SYSCALL msg=audit(11/20/2006 11:28:43.844:10) : arch=i386
syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bfffaca0 a2=b8000664
a3=1 items=0 pid=3340 auid=unknown(4294967295) uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root comm=cupsd
exe=/usr/sbin/cupsd
----
type=SOCKETCALL msg=audit(11/20/2006 16:40:46.169:16) : nargs=3 a0=6
a1=b8056720 a2=10
type=SOCKADDR msg=audit(11/20/2006 16:40:46.169:16) : saddr=inet
host:192.0.34.166 serv:123
type=SYSCALL msg=audit(11/20/2006 16:40:46.169:16) : arch=i386
syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bffff9a0 a2=b80004a8
a3=6 items=0 pid=3523 auid=unknown(4294967295) uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root comm=ntpd
exe=/usr/sbin/ntpd

Этот вывод показывает, что каждый запрос на связь порождает три записи проверки. Первая — запись SOCKETCALL, показывающая количество и значение аргументов, переданных для подключения. Вторая — запись SOCKADDR, показывающая хост через IP-адрес и используемый порт. Третья — запись SYSCALL, показывающая, был ли запрос на связь успешным, аргументы на выводе, включая ID процесса, исполняемый файл и информацию о действующем и подлинном пользователе и группе для процесса, который осуществляет вызов. Для данных целей нас главным образом интересует часть serv: записи SOCKADDR, которая показывает программу, выполняющую запрос на подключение.

Листинг 4 содержит простой скрипт, использующий команды sed и awk для сжатия вывода ausearch только в два поля, номер порта и исполняемая программа (дубликаты, отличающиеся только временем, опущены).

Листинг 4. Пример вывода auportprint.sh:
[root@localhost hpc]# ./auportprint.sh
22      /usr/sbin/sshd
123     /usr/sbin/ntpd
123     /usr/sbin/ntpdate
631     /usr/sbin/cupsd

Заключение

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

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

Большое спасибо Кайлин Холл (Kylene Hall), Дастину Киркланду (Dustin Kirkland), Флавио Ивану да Сильва (Flavio Ivan da Silva), Родриго Рубира Бранко (Rodrigo Rubira Branco) и Флавио С. Баккианти (Flavio C. Buccianti) за предоставленные ими коды, советы и участие в нелегкой работе над этой статьей.


Загрузка

ОписаниеИмяРазмер
Коды для Листингов 1, 3 и 4 из этой статьиhpc.zip4KB

Ресурсы

Научиться

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

Обсудить

Комментарии

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=Linux
ArticleID=236488
ArticleTitle=Аудит системы Linux в примерах
publish-date=06262007