 |
|
|
|
Управляем удаленными базами AIDE
Управляем удаленными базами AIDE В один прекрасный день вы решаете оснастить все ваши сервера программой локального контроля от вторжений AIDE. Осуществлению этого, несомненно правильного желания мешает только одно – сервера территориально разбросаны, а хотелось бы хранить базы AIDE на съемных носителях... Сегодня мы расскажем вам, как собрать данные со всех компьютеров, не вставая с места. Программа AIDE позволит вам контролировать изменения, происходящие в файловой системе. Для этого она создает отдельную базу данных, содержащую информацию об атрибутах файлов – дате и времени создания, дате и времени модификации, размере, владельце. База также содержит контрольную сумму содержимого файла для проверки его на неизменность содержимого. Контрольная сумма шифруется различными методами для исключения возможности ее подделки. Правильное использование AIDE гарантирует в достаточной степени неизменность файлов. Но вот работают несколько серверов, на них всех установлена AIDE, базу которой рекомендуется хранить на сменном носителе с целью не допустить попадания ее в чужие руки. Как реализовать это требование? Не вручную же копировать базу с каждого сервера? Для автоматизации этой задачи и был разработан скрипт AIDEControl. Итак:
Мы рассмотрим программу автоматического копирования баз AIDE с множества удаленных машин на некую центральную машину, обеспечивающую при этом невозможность использования данных базы в случае ее несанкционированного перехвата. Программа копирует базы на сменный носитель небольшого физического размера, а также сохраняет несколько поколений баз на сменном носителе большого обьема. Нужно ли защищаться от перехвата данных базы? Даже при невозможности ее модификации база все равно остается лакомым куском, потому что содержит список всех файлов (кроме тех, которые были исключены через конфигурационный файл) с указанием их имен, размеров, дат создания и владельцев, а это уже сама по себе немалая информация. Поэтому копирование баз будем производить через SSH с использованием скрипта, описанного в [1]. Двойное копирование последнего поколения базы необходимо потому, что последнее поколение хранится «под руками» – там, где контроль за неизменностью файлов ведется чисто визуально. Дубль же последнего поколения, а также несколько предыдущих поколений хранятся на RW-диске в сейфе, там же, где хранятся резервные копии данных. При необходимости вы всегда сможете сравнить две копии, а также провести анализ, как изменялся тот или иной файл (по предыдущим копиям базы). На рис. 1 изображена связь между мастер-компьютером, компьютерами, с которых собираются базы, и носителями. Для каждого приведено расположение файлов базы AIDE в процессе работы скрипта. Следует учесть, что это расположение баз именно в процессе работы скрипта, потому что, когда база скопирована на мастер-компьютер, она стирается с удаленного компьютера, а при завершении копирования на Flash она удаляется и с мастер-компьютера.
Рисунок 1. Расположение баз AIDE на «мастере» и удаленных компьютерах Для подключения к удаленным компьютерам скрипт использует пользовательский бюджет с именем aide. Это бюджет не для запуска скрипта, запуск скрипта делается только пользователем root. Скрипт реализован на языке Bourne shell, с использованием типового комплекта инструментов – sed, awk, grep. В качестве мастер-компьютера использовался компьютер с операционной системой FreeBSD 5.3-RELEASE, USB Flash Seitek BAR 128 Мб и CompactFlash PQI 128 Мб. Работа в других UNIX-системах не проверялась. Какое программное обеспечение потребуется Для работы скрипта необходимо установить и настроить соответствующим образом следующее програмное обеспечение:
Настраиваем систему Вам потребуются:
/dev/acd1 /cd-rw cd9660 ro,noauto,noexec 0 0
/dev/da0s1 /mnt/umass msdos rw,noauto,-l,-Wkoi2dos 0 0 (подробное описание полей fstab см. man fstab).
# Generic USB Flash drive (umass0) device "USB Flash Drive" devname "umass[0-9]+" vendor 0x058f product 0x9380 release 0x0100 attach "/sbin/mount /mnt/umass" где vendor, product и release берутся из вывода usbd, запускаемого с ключом -dv. Для каждого типа Flash значения отличаются! Вы должны подставить свои значения, получив их следующим образом: # usbd –dv
vndr – vendor (в данном случае 0x058f), prdct – product (в данном случае 0x9380), rlse – release (в данном случае 0100) подставляются в соответствующие места файла /etc/usbd.conf. Файл читается один раз при старте программы, поэтому для активации внесенных изменений usbd необходимо перезапустить: # killall usbd # usbd Внимание! Крайне не рекомендуется завершать работу usbd, запущенного с ключами -dv тогда, когда в USB вставлено какое-либо устройство, особенно если оно работает по протоколу USB 1.1! Было замечено стабильное полное зависание системы, из которого можно выйти только нажатием «Reset». Настоятельно рекомендую сначала извлечь устройство, а потом завершать работу usbd. Система должна обладать возможностью смонтировать USB Flash, а также обладать возможностью работать с IDE СD-ROM как со SCSI. Для этого в конфигурационном файле ядра системы должны присутствовать (а если их нет, то просто добавьте) следующие строки: device umass device scbus device da device pass device cd device atapicam device ata после чего ядро системы должно быть пересобрано в соответствии с инструкциями по его пересборке, приведенными, например в [3]. Кроме того, понадобится один носитель CompactFlash или USB Flash емкости, достаточной для того, чтобы вместить одно поколение копий баз со всех нужных компьютеров, упакованное Bzip2, и один CD-RW или DVD-RW-диск для хранения необходимого количества предыдущих поколений. Полный текст скрипта приведен в Приложении 1 (см. www.samag.ru, раздел «Исходный код»). Он снабжен достаточно подробными комментариями, а наиболее важные и интересные моменты мы обсудим далее по ходу статьи. Общее описание логики работы и конфигурационный файл Предполагается, что «мастер» – доверенная машина. На рис. 1 показано размещение баз AIDE в процессе их обработки скриптом. Общая связь между программами такова:
Все компьютеры, базы с которых должны собираться, описываются в файле описания узлов. Формат его очень простой: remote1 10.87.2.60 remote2 10.87.2.254 remote3 10.87.2.120 master 127.0.0.1 Последняя запись отражает тот факт, что сам «мастер» может рассматриваться и как «агент». Для этого необходимо указывать в качестве IP-адреса 127.0.0.1. AIDE на всех компьютерах, кроме «мастера», настраивается на путь к базе /var/db/aide/databases/aide.db. После копирования базы на «мастер» она удаляется. На «мастере» в каталоге databases создаются подкаталоги с именами, соответствующими именам в файле описания узлов (remote1, remote2,...), в которые база помещается на время копирования на Flash и RW-диск. После успешного копирования на съемные носители база удаляется с «мастера» и существует только на съемных носителях. Конфигурационный файл программы по формату предельно прост: поскольку сама программа написана на языке Bourne Shell, загрузка конфигурационных файлов проводится выполнением файла и, следовательно, формат имеет вид «имя=значение». Имя файла по умолчанию – /usr/local/etc/aidecontrol.conf, все возможные переменные описаны непосредственно в тексте файла. Пример файла приведен в Приложении 2 (см. www.samag.ru, раздел «Исходный код»). Блок-схема программы Блок-схема программы приведена на рис. 2. Сбоку, на выносках отмечены метки блоков, приводимые в комментариях текста скрипта в Приложении 1 (см. www.samag.ru, раздел «Исходный код»).
Рисунок 2. Блок-схема скрипта AIDEcontrol Первыми выполняются анализ командной строки и установка значений, заданных в параметрах. Соответствующая метка в скрипте – CMDLINE. Возможные ключи командной строки:
Таким образом: // запустит скрипт с параметрами по умолчанию # aidecontrol // запустит скрипт с параметрами из конфигурационного файла /tmp/abcd.conf # aidecontrol -c /tmp/abcd.conf // запустит скрипт со списком узлов из файла /tmp/nodes.lst и чистым RW-носителем. # aidecontrol -l /tmp/nodes.lst -b Если в командной строке был задан вывод краткой справки, то она выводится и скрипт завершает работу, иначе выполняется загрузка конфигурационного файла. После загрузки выполняется поиск вспомогательных программ. Он имеет такую особенность, что программы, которые необходимы для работы, перечислены непосредственно в переменной wtools. Причем в этом списке не упоминается mkisofs, потому что burniso сам проверит ее наличие. Соответствующая метка в листинге WTOOLS. Эта часть показалась мне достойной более подробного рассмотрения, которое приведено ниже. wtools="bzip2 burniso" for tool in $tools do # Вот это список программ, без которых работа невозможна (не считая SSH) locator=`which $tool` # Если which вернул пустую строку (а это происходит тогда, когда программа не найдена – ее физически нет # или каталог не включен в PATH), то выдать сообщение и прекратить работу if [ -z $locator ]; then logline="Your system does not include $tool utility"; safe_logger exit fi done Реализация поиска SSH в скрипте полностью аналогична реализации скрипта safecopy, описанного в [1]. Соответствующая метка в листинге SEARCHSSH. Дополнительно процесс поиска описан в комментариях в тексте скрипта. После того как проверено наличие всех необходимых программ, начинается разбор списка узлов. Этот разбор будет делаться в течение работы скрипта неоднократно, но особенности процесса его выполнения будут рассмотрены один раз. Разбор производится посредством простого чтения файла командой cat. Для построчной работы с файлом используется особенность работы с потоком стандартного ввода, которая заключается в том, что при чтении файла все прочитанное разбивается на «поля», где значение переменной IFS используется как разделитель. Если изменить ее значение, а потом прочитать файл, разбиение на «поля» будет выполняться в соответствии с новым значением IFS. Поскольку нам необходимо разобрать по записям (строкам), используется следующая конструкция: IFS=" " Внимание! Значение «IFS=’’», перенесенное на соседнюю строчку, – это не ошибка! Таким образом IFS присваивается значение «конец строки» ( ), после чего организуется обычный цикл перебора всех записей файла. Если адресом компьютера является 127.0.0.1, то выполняется локальное копирование, то есть просто копирование базы AIDE в то место, откуда она впоследствии будет перенесена на съемный носитель. Соответствующая метка в листинге LOCALCOPY. Если же нет – предполагается удаленный компьютер и выполняется копирование с удаленного компьютера. Процесс получения списка файлов, подлежащих копированию, и собственно процесс копирования полностью аналогичны процессу, описанному в [1]. Процесс получения списка файлов здесь вырождается просто в еще одну проверку правильности настроек SSH, поскольку список файлов может содержать только один элемент (или не содержать ни одного, что будет указывать на ошибку). Соответствующая метка в листинге RMTCOPY. Если при запуске скрипта не было указано, что установлен чистый носитель, то RW-диск монтируется и его содержимое копируется во временный каталог, создаваемый в корневом каталоге системы. Соответствующая метка в листниге MNTRWDISK. Особенности монтирования съемных носителей состоят в том, что их наличие проверяется в бесконечном цикле до тех пор, пока носитель не будет установлен и подключен. Сделано так потому, что на первом этапе базы не копируются, а переносятся на «мастер» и при отмене и повторном запуске скрипта базы не будут найдены. Поэтому лучше разобраться с причиной невозможности смонтировать диск (а это, как правило, банальная причина – опущен ключ -b при установке чистого диска, отсутствует или неверно указана точка монтирования и т. д) и попытаться смонтировать его повторно. После каждой безуспешной попытки смонтировать диск программа спрашивает, не желаем ли мы пропустить попытку монтирования диска. Если согласиться с ней и монтирование диска пропустить, то диск будет помечен как чистый, чтение с него выполняться не будет, все его предыдущее содержимое будет перезаписано. Если RW-диск успешно смонтирован, то происходит реорганизация его содержимого – файлы, поколение которых превышает максимально хранимое поколение, будут удалены, остальные переименованы в следующее поколение. Процедура последовательного переименования файлов (filename.0.ext filename.1.ext filename.2.ext и т. д.) будет описана несколько более подробно. Метка процедуры в листинге – RENAME, метка самой процедуры реорганизации – RWREORDER. shiftfiles() { # Получаем список файлов в каталоге lfiles=`ls -1` # Обрабатываем по одному элементу списка до тех пор, пока он не пуст for lfile in $lfiles do # Выбираем номер поколения (указываем awk, что разделителем полей является точка, и печатаем второе поле) gener=`echo $lfile | awk 'BEGIN {FS="."} {print $2}'` # Дополнительная защита – если в качестве номера поколения выбрали «bz2», значит в каталоге # находится файл filename.bz2,который не переименован из-за какой-либо ошибки. Корректируем эту ситуацию, # подразумевая нулевое (самое последнее) поколение if [ $gener = "bz2" ]; then logline="Invalid database file name $lfile, assumed zero generation"; safe_logger gener=0 mv $adbnam.bz2 $adbnam.$gener.bz2 fi # Если номер поколения равен максимально хранимому поколению, этот файл удаляется. Иначе вычисляется # следующий номер и файл переименовывается. if [ $gener -eq $abmax ]; then rm -f $adbnam.$gener.bz2 else ngener=$(($gener+1)) mv $adbnam.$gener.bz2 $adbnam.$ngener.bz2 fi done } В случае когда выполнялась установка чистого носителя, то копировать нечего и просто создается пустой каталог для копирования в него последнего поколения баз. if [ $blank = "no" ]; then shiftfiles fi cp $ringdir/$hostname/$adbnam.bz2 ./$adbnam.0.bz2 После этого выполняется запись нового содержимого RW-диска. Особенностью записи нового образа с полным количеством поколений баз является использование скрипта burniso. Этот скрипт был написан для автоматизации задачи «взять все файлы, лежащие в определенном месте и записать их на RW, предварительно его почистив». Для создания образа burniso использует mkisofs, а для записи – cdrecord. Скрипт имеет собственный конфигурационный файл burniso.conf, синтаксис которого полностью аналогичен синтаксису aidecontrol.conf. В нем можно указать три переменных: workdir – каталог, в котором будет создаваться образ для последуюшей записи, devname – имя устройства для записи дисков и sourcedir – каталог, из которого будут браться файлы для записи на RW. Имя устройства задается в формате cdrecord в виде «bus,target.lun», например devname=«2,1,0». Внимание! Приведенные выше значения являются примером использования. На вашей системе они будут отличаться! Получить значения, которые необходимо подставить сюда, можно командой: # camcontrol devlist
В данном случае использовалось устройство TEAC CDW58E (2,1,0). Более подробную информацию о возможностях cdrecord см. man cdrecord. Запись диска может идти достаточно долго, перед началом записи cdrecord выводит большое количество информации о приводе, о диске, на который будет идти запись, о режимах работы... Ход выполнения записи отображается на консоли в виде:
После записи диска со всеми поколениями копий временный каталог, в котором создавался образ для записи на RW-диск, удаляется. Последней фазой работы скрипта является перенос на Flash последней копии баз по всем узлам. Для этого сначала монтируется Flash. Монтирование происходит аналогично монтированию RW-диска – в бесконечном цикле. Ваша система должна быть уже настроена на автоматическое монтирование Flash при ее установке. О том, как это сделать, написано в разделе «Настраиваем систему». Вполне возможно, что /sbin/mount не будет успевать отработать монтирование устройства в FreeBSD 5.x, поскольку файлы устройств здесь создаются динамически, а devfs имеет некоторое время срабатывания. В особенности это проявляется на старых Flash 1.1 типа Seitek BAR – требуемая задержка может достигать двух секунд. Для избежания этого был разработан скрипт mountflash, приведенный в Приложении 3 (см. www.samag.ru, раздел «Исходный код»). Скрипт может запускаться как вручную, так и через /etc/usbd.conf. В последнем случае строка attach должна иметь следующий вид: attach "sh -c "/usr/local/bin/mountflash /mount/point"" где /mount/point – точка монтирования Flash. По умолчанию точка монтирования – /mnt/umass. Метка монтирования Flash в листинге – MNTFLASH. В очередной раз выполняется разбор файла описания узлов и по одному узлу за один проход выполняется копирование файлов из соответствующего каталога на мастер-компьютере в соответствующий каталог на Flash. Если копирование файла прошло успешно, файл удаляется с мастер-компьютера. Метка в листинге – FLASHCOPY. Последней задачей скрипта является размонтирование Flash и останов устройства. Эта часть будет рассмотрена более подробно ниже по тексту. # /dev/da0s1 mpdev=`mount | grep -e "$usbdevmp " | awk '{print substr($1,6,3)}'` # Размонтировать Flash umount $usbdevmp status=$? # Проверить статус размонтирования и выдать сообщение, если неудачно if [ $status -ne 0 ]; then logline="USB Flashdrive unmounting on device $usbdev failed, return code is $status"; safe_logger else logline="USB Flashdrive was succesfully unmounted after updating content"; safe_logger # Найти устройство, на которое смонтировалась Flash. Устройство находится поиском в выводе команды # camcontrol devlist строки «(<имя_устройства», например «(da0» umdrive=`camcontrol devlist | grep -e "($mpdev"` # Выбрать BUS. Ищется строка «scbusX», потом берется подстрока с шестого символа от места, где найдена строка umbus=`echo $umdrive | awk '{print substr($0,index($0,"scbus"),6)}'` umdig=`echo $umbus | awk '{print substr($1,6)}'` # Так же ищется target и lun. target берется через 7 ("target ") символов от строки, # lun берется через 4 ("lun ") символа от строки umtarget=`echo $umdrive | awk '{print substr($0,index($0,"target") + 7,1)}'` umlun=`echo $umdrive | awk '{print substr($0,index($0,"lun") + 4,1)}'` # Выдать команду останова устройства (она погасит индикатор готовности на Flash, за исключением USB 1.1) camcontrol eject $umdig:$umtarget:$umlun fi Возможные ошибки Если скрипт работает не так, как ожидается, то, возможно, имеет место ошибка в настройке SSH. Это очень просто проверить – достаточно с консоли мастер-компьютера набрать: # su aide > ssh remotebox где remotebox – имя любого компьютера, с которого должны копироваться базы. Если сразу же открывается терминал удаленного компьютера – все нормально (при этом motd показываться не должно). Если же появляются запрос пароля на разблокирование ключа, запрос пароля на регистрацию на удаленном компьютере или какие-либо сообщения об ошибках – следует устранить ошибки и повторить. Все наиболее типичные ошибки, связанные с настройкой SSH для автоматического копирования файлов с использованием метода авторизации по публичному ключу, приведены в [1]. Наиболее часто встречающиеся ошибки, не связанные с настройками SSH:
Наиболее уязвимым является процесс монтирования и размонтирования Flash, поскольку он требует значительного числа предварительных настроек. Для проверки успешного монтирования Flash следует запустить usbd в режиме отладки и посмотреть, не появляются ли сообщения об ошибках во время процесса монтирования Flash. Следует учесть, что даже для Flash одного типа могут быть разные release. Гарантированно одинаковыми являются только Flash из одной коробки. Заключение Данный скрипт – инструмент, который поможет вам решить одну конкретную задачу. Несмотря на кажущуюся громоздкость, он относится к классу программ «настроил и забыл» – после двух-трех успешных циклов получения информации запуск скрипта можно было бы уже доверить младшему персоналу, если бы не крайняя важность копируемых данных. Проверять систему с использованием скопированных файлов можно либо с помощью скрипта AIDEstart, который будет описан в следующей статье, либо с загружаемой USB Flash, либо вручную, указывая путь к данным в конфигурационном файле или при запуске AIDE. Литература и ссылки:
|
РАШИД АЧИЛОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
