[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Операционные системы" / Оглавление документа

6. Cfengine и механизмы для работы с сетями

В данной главе рассказывается о том, как настроить механизмы работы с сетью cfengine для того, чтобы осуществлять удалённое распределение файлов и удалённый запуск cfengine, не подвергая при этом компьютеры возможным атакам, возникающим при использовании rsh протоколов.

Contents

6.1. Возможности cfengine по работе с сетью

Запустив демон, называемый cfservd, можно установить линию связи между компьютерами, что позволит им обмениваться файлами по сети и осуществлять удалённый запуск cfengine с другой системы. Возможности cfengine по работе с сетью реализуются с помощью следующих компонентов:

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

6.2. принцип действия

6.2.1. Удалённое распространение файлов

Данный раздел посвящён настройке cfservd в качестве удалённого файл-сервера, что позволит распространять файлы на компьютеры клиентов более демократичным способом, чем с помощью программ типа rdist.

Важное отличие между cfengine и другими системами заключается в способе распространения файлов. При передаче сетевых файлов cfengine использует схему, при которой, скорее, компьютеры берут, нежели сервер раздаёт. Например, принцип работы команды rdist заключается в том, чтобы заставить все клиентские компьютеры принять копии файлов с одного сервера. При желании сервера файлы могут изменяться, но пользователям ничего не остаётся, как получать результат. Cfagent не может заставить другие компьютеры выполнять его желания таким образом. Он может лишь информировать хосты и предложить им при желании загрузить файлы. Другими словами, cfengine имитирует работу по раздаче файлов, опрашивая каждый компьютер и запуская локальный конфигурационный скрипт, который позволяет загрузить и обновить файлы с удалённого сервера, при чём каждый клиент сам принимает решение о необходимости обновлений.

Кроме того, в отличии от таких программ, как rdist, распространяющих программы на множество компьютеров, cfengine не требует никакого общего корневого доступа к системе с использованием файлов .rhosts или /etc/hosts.equiv. Достаточно просто запустить демон в качестве корня. Однако, его нельзя запустить, добавив в файл /etc/inetd.cof системы. Ограниченные возможности демона защищают систему от попыток выполнять основные команды как привилегированный пользователь, используя rsh.

Для удалённого доступа к фалам на сервере необходимо добавить ключевое слово server=host в команду копирования copy. В следующем примере рассматривается, как можно передать файл с паролем с главного компьютера нескольким клиентским.

copy:
PasswdClients::
/etc/passwd dest=/etc/passwd owner=root group=0 server=server-host

Учитывая, что демон cfservd запущен на компьютере-сервере, cfagent установит с ним связь и попытается получить информацию о файле. В течение этого процесса cfengine удостоверится в том, что системные часы на обоих компьютерах достаточно синхронизированы. В противном случае, он не позволит удалённое копирование. Если cfagent установит необходимость обновить файл с удалённого сервера, то он начнёт копировать удалённый файл в новый в той же файловой системе, где должен находиться файл результатов. Этот файл имеет суффикс .cfnew. Только после того, как файл был успешно собран, cfagent скопирует старый файл (см. repository в приложении к руководству) и назовёт новый его именем. Такой принцип используется для того, чтобы избежать состояния гонок (race-conditions), которые могут возникать в ходе сетевых соединений и ,более того, операций, на которые требуется время. Если бы файлы просто копировались на их новые места, то вероятно, что ошибка в сети могла бы прервать передачу, оставляя взамен искажённый файл.

Для того, чтобы избежать зависаний процессов, cfagent делает в сетевых соединениях тайм-ауты на несколько секунд.

Как правило, демон бездействует, ожидания соединений от сети. Такое соединение может возникнуть в результате просьбы получить удалённые файлы, исходящей от программы на другом компьютере, запустившей cfagent. Также соединение может быть установлено программой cfrun, которая просто запрашивает компьютер с работающим демоном локально запустить программу cfengine.

6.2.2 Удалённый запуск cfagent

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

myhost% cfrun remote-host -v
output....

Для реализации такой возможности был создан простой пользовательский интерфейс. cfrun устанавливает соединение с удалённым cfservd -демоном и запускает cfagent в системе, которая обладает привилегиями cfservd-демона (обычно это root). В данном процессе есть два преимущества:

• Не нужно входить на удалённый компьютер для того, чтобы поменять его конфигурацию.
• Не только пользователи, относящиеся к root, могут запускать cfagent для решения проблем, возникающих на их системах.

Возможный недостаток использования такой системы заключается в том, что злоумышленник имеет возможность запуска cfagent на удалённых компьютерах. Тот факт, что не только пользователи root могут запускать cfagent, не является проблемой самой по себе, поскольку самое плохое, что они могут сделать просмотреть конфигурацию системы и исправить какие-либо возникшие проблемы. С помощью программы cfrun невозможно раздавать cfagent указания, возможно лишь запускать уже созданную конфигурацию. Но большую опасность могут вызвать попытки злоумышленника повторно запускать cfagent (так называемый, спамминг), в следствие чего система становиться загруженной постоянными запусками cfagent. См раздел 6.2.3. [Спамминг и безопасность].

6.2.3. Спамминг и безопасность

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

Каждый раз при подключении системы к сети, эта проблема всплывает заново. Cfagent является инструментом для организации взаимодействия систем, но не орудием, которое можно использовать в периоды бессмысленной агрессии. Однако, демон cfservd позволяет каждому подключаться к сети и запускать процесс cfengine, в связи с чем требуется наличие механизма защиты от подобных атак.

Cfagent решает данную проблему при помощи блокирующих механизмов. Вместо того, чтобы организовывать управление согласно статусам пользователей, он использует блокирующие механизмы, основанные на классах времени. Они позволяют пользователям совершать действия только по истечении определённого минимума с момента последнего момента их выполнения. Использование блокировщика, основанного не на идентификации пользователей, позволяет одновременно удовлетворить несколько целей:

• Ограничение доступа cfengine к корню не позволит обычным пользователям решить возникшие проблемы, если администратор по каким-либо причинам недоступен. Блокировщик, основанный на времени, не забирает у пользователей таких возможности.

• Неполадки в скриптах cron или shell могут привести к более частому, чем запланировано, запуску cfagent. Необходимо также гарантировать защиту и от таких случаев.

• Предотвращать атаки можно вне зависимости от того, кто их осуществляет.

Cfagent контролируется набором блокировщиков, которые не позволяют запускать его слишком часто и тратить слишком много времени, пытаясь выполнить задание. Работа блокировщиков устроена таким образом, что она позволяет осуществлять одновременный запуск нескольких cfengine, избегая столкновений между ними. Исполняющиеся в одно и то же время процессы cfengine также не смогут одновременно выполнять одинаковые действия (это называется спамминг). В последовательности действий action sequence можно осуществлять контроль сразу за двумя аспектами каждого действия:

• Минимальный промежуток времени, который должен пройти с последнего момента выполнения действия (по умолчанию, 1 минута).
• Максимальный промежуток времени, который cfagent должен ждать до окончания выполнения старого cfagent, перед тем как выключить его и запуститься снова (по умолчанию, 120 минут).

Данные значения могут быть установлены глобально (для всей системы) и для каждого действия по отдельности. При установке, как глобальных, так и локальных значений, приоритет будет отдаваться локальным. Время всегда задаётся в минутах.

actionsequence
(
action.IfElapsedtime-in-mins
action.ExpireAftertime-in-mins
)

Или глобально

control:
IfElapsed = ( time-in-mins )
ExpireAfter = ( time-in-mins )

Например,

control:
actionsequence =
(
files.IfElapsed240.ExpireAfter180
copy
tidy
)
IfElapsed = ( 30 )

В данном примере действие files воспринимается не как все остальные. Для всех остальных действий cfagent исполнит файловую часть программы, только если прошло 30 минут с момента её последнего запуска. Поскольку никакого значения не установлено, время истечения для действий составляет 60 минут. Это значит, что любой процесс cfengine, который не успел закончить задание в течение 60 минут, будет автоматически прекращён следующим запускающимся cfagent.

Что касается действия files: оно будет выполняться только по прошествии 240 минут (4 часа) с момента последнего запуска. Аналогично, процесс выполнения files будет прекращён, только по прошествии 180 минут (3 часа).

Данные блокировщики не мешают запуску целого cfagent, а лишь его так называемым атомам. Несколько разных атомов может одновременно запускаться разными cfagent. Допустим, что временные ограничения, установленные выше, позволяют произвести запуск cfengine. Блокировщики гарантируют, что атомы никогда не будут запущены двумя cfagent одновременно, что может привести к конфликту и испортить циклы CPU. Атомы определяются для того, чтобы обеспечивать эффективность и большую безопасность системы. Если бы cfangine блокировал каждый файл, рассматриваемый в отдельности, он бы тратил большое количество времени на работу с блокировщиками, поэтому он этого не делает. Вместо этого он группирует всё вместе, подобно следующему:

Cfagent создаёт директорию `~/.cfengine' для написания блокирующих файлов для обычных пользователей.

Опции -K или --no-lock используются для отмены блокировщиков, но следует обратить внимание, что эти опции недоступны при удалённом запуске cfagent через cfservd.

6.2.4 Немного о протоколе cfserved

Для авторизации на компьютерах cfservd использует форму. Каждая маленькая операция, например, статтинг(statting), получение файлов, открытие папок и т.д., требует нового соединения, и каждое соединение проверяется с помощью двустороннего поиска в DNS записях сервера. Одиночные стат структуры(stat structures) кэшируются в ходе обработки файла.

Контрольные суммы MD5 передаются от клиента серверу с целью избежать перегрузки сервера. Даже если бы пользователь мог исказить контрольную сумму MD5, ему или ей пришлось бы пройти контроль доступа последнего IP и самое страшное, что могло бы произойти в таком случае получить правильную версию файла. Всё это придерживается одной идеи, что с помощью cfengine пользователь может навредить только себе, но не другим пользователям.

6.2.5. Конфликт блокировок и бесконечные циклы

Каждый раз, как только запущенным процессам разрешается одновременный доступ к одному ресурсу, возникает опасность возникновения конфликта блокировок. Так называется ситуация, когда два или более процессов попадают в возникшее по ошибке тупиковое положение, из которого ни один не может выйти. Другой возможной проблемой является опасность зацикливания: cfagent запускает сам себя.

Cfagent надёжно защищает от возникновения таких циклов. Случайное создание подобного цикла должно быть невозможным. Такую гарантию дают блокирующие механизмы, которые предотвращают возможность частого повторения заданий. Если запустить процесс cfagent, содержащий команду shell, которая снова запускает cfagent, то такая команда будет блокирована, поэтому повторный запуск окажется невозможным. Таким образом, даже если существует возможность начала второго процесса cfagent, то дальнейшие процессы не будут запущены, в результате чего, просто потратится немного времени CPU. По возвращении первого cfagent, задание, которое выполнил второй, будет повторно исполнено исключительно в том случае, если значение IfElapsed или ExpireAfter равно нулю. В целом, во избежание подобных проблем не стоит отключать блокирующие механизмы, установкой нулевых значений.

Вероятность возникновения конфликта блокировок увеличивается в ходе сетевых соединений. Cfengine не станет использовать сеть для копирования файла, который можно скопировать внутренне непосредственно с другого компьютера. Чтобы избежать ненужных сетевых соединений, он всегда будет в копии заменять объявление server= на localhost. Это позволяет иссключить одну из возможных тупиковых ситуации, а именно, cfrun выполняет cfagent на компьютере А (cfservd на компьютере А будет блокирован до окончания этого процесса), но файл конфигурации компьютера А содержит удалённую копию с себя на себя же. Такая удалённая копия будет ждать, пока не разблокируется cfservd, что оказывается невозможным, поскольку cfservd не может быть разблокирован, пока у него есть этот файл. Возможность возникновения такой ситуации устраняется, путём запрещения удалённых копий на localhost.

6.3. Конфигурация cfservd

6.3.1 Инсталяция cfservd

Для установки демона cfservd, необходимо зарегистрировать порт для cfengine. Для этого  в системный файл нужно добавить следующую строчку: `/etc/services file'

cfengine 5308/tcp

Это можно проделать для всех компьютеров, если добавить следующие строки в конфигурацию cfengine

editfiles:
{ /etc/services
AppendIfNoSuchLine "cfengine 5308/tcp"
}

Для того, чтобы запустить cfservd во время загрузки, в файлы запуска необходимо добавить строчку подобного вида:

# Start cfengine server
cfservd

Обратите внимание, что cfservd будет перечитывать свой файл конфигурации, каждый раз когда он заметит в нём внесённые изменения. Поэтому нет необходимости ни перезапускать демон, ни посылать сигнал HUP, как при работе с другими демонами.

6.3.2 Файл конфигурации cfservd.conf

Демон сервера управляется файлом cfservd.conf. Синтаксис данного файла намеренно строился по аналогии с файлом конфигурации cfengine, но несмотря на все сходства, нельзя путать их содержание.

Несмотря на того, что cfagent.conf и cfservd.conf не совместимы, у них есть ряд общих черт:

• Для обозначения записей в обоих файлах используются классы, поэтому один и тот же файл конфигурации можно использовать для управления всеми компьютерами сети. Это удобство позволяет устранить проблему поддержания нескольких разных файлов.
• Оба файла проверяются на использование содержания переменной CFINPUTS.
• В обоих файлах можно использовать groups и import для разбивки файлов на удобные модули и вставки общих ресурсов, таких как списки или группы.

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

Идентификация имени компьютера осуществляется не по классу или группе, а по его имени hostname, например, файл /etc/exports в большинстве систем Unix. Синтаксис для такого файла выглядит примерно следующим образом:

_ _
control:
classes::
domain = ( DNS-domain-name )
cfrunCommand = ( "script/filename" ) # Quoted
MaxConnections = ( maximum number of forked daemons )
IfElapsed = ( time-in-minutes )
DenyBadClocks = ( false )
AllowConnectionsFrom = ( IP numbers )
DenyConnectionsFrom = ( IP numbers )
AllMultipleConnectionsFrom = ( IP numbers )
LogAllConnections = ( false/true )
SkipVerify = ( IP numbers )
groups:
Group definitions
import:
Files to import
admit: | grant:
classes::
/file-or-directory
wildcards/hostnames
deny:
classes::
/file-or-directory
wildcards/hostnames root=hostlist encrypt=true/on

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

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

В данном файле необходимо использовать полностью уточнённые имена компьютеров, в противном случае к ним добавляется текущий домен (не забудьте задать доменное имя). Идентификация вызывает функцию Unix gethostbyname() и так далее для того, чтобы распознать и проверить подключающиеся компьютеры. Поэтому имена в файле должны отражать типы имён, возвращаемые данной функцией. Для того, чтобы задать, например, все компьютеры с определённого домена, при определении имён можно использовать групповые символы. В качестве примера приведём файл:

#####################################################
#
# This is a cfservd config file
#
#####################################################
groups:
PasswdHost = ( nexus )
#####################################################
control:
#
# Assuming CFINPUTS is defined
#
cfrunCommand = ( "/var/cfengine/bin/cfagent" )
variable = ( /usr/local/publicfiles )
#####################################################
admit: # Can also call this grant:
# Note that we must grant access to the
# agent if we wan to start it remotely with cfrun
/var/cfengine/bin/cfagent
PasswdHost::
/etc/passwd
*.iu.hioslo.no
FtpHost::
# An alternative to ftp, grant anyone
/local/ftp/pub
*
# These file paths must not contain symbolic
# links. Access control does not follow symlinks.
any::
$CFINPUTS/cfrun.sh
*.iu.hioslo.no
#####################################################
deny:
/etc/services
borg.iu.hioslo.no
/local/ftp
*.pain-in-the-ass.com

 Внимаение I: cfserved не является rpc.mountd, контроль доспупа происходит по имени файла filename, а не по имени устройства. Не стоит думать, что файлы, лежащие в поддиректориях, не доступны просто потому, что они находятся на другом устройстве. Для того, чтобы избежать символических ссылок, необходимо задавать полный адрес к файлу.

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

Внимание III: Cfservd требует предоставлять доступ к файлам, избегая каких-либо символических ссылок. Для того, чтобы получить доступ к файловому объекту, необходимо предоставить доступ к существующему файлу или директории.

Это служит целям безопасности на случай, если группы с доступом по логину к серверу могут предоставить доступ к дополнительным файлам, используя возможность создавать символические ссылки во временной директории, например, /tmp.

Партнёры:

Хостинг: