Журнал LinuxFormat - перейти на главную

LXF146:tut9

Материал из Linuxformat
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Админу сервера: Настройка

В развитие прошлого урока, Стюарт Бернс показывает простой способ расширить установку системы и обновить ряд главных установок безопасности.


Месяц назад мы рассмотрели основы установки новой системы, используя автоматизированный kickstart системы RedHat и видоизменив его под свои цели.

Мы брали простые средства, чтобы создать web-сервер, предоставляющий установочные файлы, и изменили kickstart, чтобы установить еще один сервер – а при желании и больше.

Мы взяли kickstart, сгенерированный установкой (каждая установка RH/Centos создает установочный скрипт под названием anaconda-ks.cfg, который копируется в /root/).

Также мы обсудили использование утилиты настройки Kickstart (по умолчанию она не установлена) и изменили ее в соответствии с нашими требованиями. Для использования настроек мы передали ее в командную строку при загрузке с CD, с помощью команды 

linux ks=http://url to your web server/kickstart folder/kickstart file

В моем случае пример выглядит так: 

linux ks=http://192.168.1.6/kickstarts/kickstart.cfg

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

Использование kickstart – только первая часть автоматической настройки и конфигурирования системы. Также мы рассмотрим обновление безопасности текущей установки ОС. Мы собираемся

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


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

Создается локальный репозиторий «в лоб». На главном [master] web-сервере, где содержится файлы вашего kickstart, создайте каталог под названием updates в корневой папке web-сервера (/var/www/html/updates) – туда будут помещаться скачанные вами обновления. Вам также следует задать права доступа к этой папке. Для этого воспользуйтесь от имени root следующими командами: 

mkdir /var/www/html/updates
chmod 644 /var/www/html/updates

Затем следует настроить систему на скачивание обновлений командой rsync, сделав эти обновления доступными другим серверам по локальной сети.

Чтобы выбрать, с какого сервера rsync скачивать, обратитесь к сайту, содержащему зеркала rsync: (http://www.centos.org/modules/tinycontent/index.php?id=31).

Все это нужно проделать только для сервера обновлений, а тот предоставит содержимое другим нашим серверам. Убедитесь, что вы синхронизируете правильные обновления: я использую Centos 5.6, а вы сможете узнать, какой релиз используете, заглянув в файл /etc/redhat-release.

Команда для rsync имеет следующий вид: 

/usr/bin/rsync -avH --exclude 'isos' rsync://rysnc site/centos/5.6/* /var/www/html/updates

Чтобы получать все свежие обновления и заплатки безопасности, эту команду следует вызывать не единожды, и хорошей идеей будет проделывать автоматическое обновление где-нибудь поутру. Не обязательно пользоваться rsync – можно использовать FTP или что-либо подобное; но это будет крайне неэффективно. (Дополнительная информация о rsync – во врезке справа.) Создание задачи cron для rsync проще простого.

Для еженедельного автоматического скачивания обновлений либо воспользуйтесь visudo, встроенной утилитой управления cron, либо автоматически установите задачи cron. Для нашего дела мы малость схитрим, однако задача будет выполняться исправно и давать те же результаты, а путь прямой. Обновления будут проверяться каждую субботу в 3:30 ночи. Если у вас другая версия Centos, вам придется слегка видоизменить команду: 

echo “30 3 * * 6 /usr/bin/rsync -avH --exclude ‘isos’ rsync://mirror.bytemark.co.uk/centos/5.6/* /var/www/html/updates” >> /var/spool/cron/root

Скрипт %post пригоден и для других задач – например, для передачи по FTP.

Задачи cron (для всех пользователей) помещаются в /var/spool/cron. Там перечислены все пользователи, у которых имеется cron.

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

Существуют две вещи, которые задают репозиторий с точки зрения клиента: файл /etc/yum.conf и каталог /etc/yum.repos.d/. Чтобы у нас было все чистенько, разместим наш репозиторий в папке yum.repos.d, содержащей все репозитории, о которых знает система.

Ниже дан пример типового файла repo. Установщик yum, при выполнении любых действий с ним, обращается к файлам yum.repos.d и yum.conf и определяет оттуда доступные репозитории. Здесь доступен только один – я вставил комментарии, чтобы было понятно, что происходит.

Чтобы создать собственный «спецрепозиторий», нужно скопировать существующий; назовем копию lan.repo. Изменения репозитория на сервере должны выглядеть так: 

cp /etc/yum.repos.d/Centos-Base.repo /var/www/html/postinstall/config/lan.repo

При необходимости отредактируйте новый репозиторий, произведя изменения в расположении (baseurl): 

[LAN Repo] # Короткое имя репозитория. Сделайте его осмысленным
name=LAN Repo # Текстовая деталь, $release - переменная, содержащая номер текущего релиза
baseurl=http://url to local update server/updates/os/$basearch # Здесь будут сохранены изменения
gpgcheck=1 # Будем ли мы устанавливать только подписанные пакеты?
enabled=1 # Хотим ли мы активировать этот репозиторий?
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5 # Ключ-подпись. Можно оставить его как есть, потому что мы не используем файлы не из Centos.


Если вам интересно увидеть, что происходит, когда yum берется за дело, просто воспользуйтесь опцией -v в команде yum. Также с файлом репозитория можно использовать две переменные: $basearch и $releasever.

Они могут пригодиться, если вы работаете не с одной архитектурой (например, с i386 и x86_64). Это не обязательное требование, но поможет отделить части репозитория, предназначенные различным системам. Например, если я использую 64-разрядную ОС, $basearch будет использовать каталог x86_64 А будь я на чипе, основанном на Intel 386, то это была бы папка i386. То же самое относится к $basearch. Она возвращает версию используемой ОС; это полезно при запуске нескольких разных релизов Centos/RH.

Чтобы добавить новый репозиторий, скопируйте существующий файл и подправьте его в соответствии с нашими нуждами. Создав правильно отредактированный файл, мы можем скопировать файл yum repository на web-сервер (или использовать файл, имеющийся на web-сервере) и скопировать его в папку /var/www/html/post-install. Не забудьте сменить владельца файла, а также группу и права доступа. 

cd /etc/yum.repos.d
cp lan.repo /var/www/html/postinstall/
chmod 644 /var/www/html/postinstall/config/lan.repo

Сейчас мы можем добавить этот файл репозитория в раздел postinstall нашего базового kickstart. Остальные репозитории просто удалите из папки etc/yum.repos.d/. Если оставить там старые, мы не сможем пользоваться ими в нормальных сетях – по причине заботы о безопасности порты для внутренних серверов будут закрыты, и обновления не произойдет.

Чтобы обновление вошло в системы, которые будут развернуты в будущем, добавим его в пост-установку. И опять, лучше всего оформить его как установочный скрипт. Создайте следующий файл /var/www/html/postinstall/scripts/repo.sh: 

cd /etc/yum.repos.d
rm *.repo # Удалите все предыдущие репозитории.
wget http://url of server/postinstall/config/lan.repo # и замените их нашим.
yum clean all # Удаляет ссылки на базы данных yum, используемые старыми репозиториями.
yum -y update

Не забудьте добавить это в раздел %post базового файла kickstart. Измените раздел %post базовой конфигурации kickstart: 

%post
cd /tmp
get http://url to web server/postinstall/scripts/repo.sh
chmod +x repo.sh
./repo.sh

Тогда любое обновление, действия с yum или rpm будут разговаривать только с репозиторием в вашей локальной сети, а не с другими. Установка этого скрипта также автоматически обновит установку (ее часть с yum -y). Предупреждаем, однако, что обновления потребуют времени – может показаться, что все зависло, но выполнение будет идти в фоновом режиме.

Чтобы убедиться в правильности работы вашего репозитория, воспользуйтесь командой yum -v repolist. Она выводит список только видимых репозиториев. В нашем случае должен быть только один, новый, и никаких других. Новые серверы, которые мы собираем, будут автоматически обновляться и содержать локальные репозитории для получения данных, и теперь можно поискать добавление к базовой безопасности.

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

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

В главном скрипте безопасности измените порт ssh, вставьте пометки и убедитесь, что пользователь root или пользователи с должными привилегиями могут выполнить прямой вход. И снова, это скорее пример того, что можно сделать, а не того, что нужно сделать.

Можно задать весь скрипт, чтобы он менял баннер строку за строкой, но зачем же усложнять? Проще скопировать наш баннер, заранее исправленный ssh config, и перезапустить службы sshd. Надо включить файл-баннер, так что давайте внесем их всех в один пакет и развернем скриптом пост-установки. Простым копированием предопределенных файлов настройки можно достичь многого, но чтобы они попали на будущие серверы, нужен скрипт.

Во-первых, возьмем копию существующего файла sshd_config и исправим ее. Для хранения всех этих файлов нужен каталог, поэтому скопируем /etc/ssh/sshd/sshd_config в папку /var/www/html/postinstall/config, и установим файлу такие права, чтобы каждый мог читать его. (Например, поменяем владельца и группу и установим права равными 644, как уже проделывалось для подобных конфигураций.)

Простейшим началом будет упрочить ssh. Это не исчерпывающий список, он просто служит примером.

Изменения, делающие его более безопасным, приведены ниже. Используйте vi или любой другой редактор с web-сервера, чтобы изменить файл /var/www/html/postinstall/config/sshd_config: 

Port 300 # Меняет порт ssh по умолчанию в вашей системе. Применяйте с осторожностью. Если вы это сделаете, может понадобиться менять правила брандмауэра!
DenyGroups root # Предотвращает прямой вход пользователей из группы root
Banner /etc/banner # Полезно для предупреждений и отпугивающих вывесок.

Ниже дан небольшой пример базового скрипта безопасности, который установит пользовательский sshd config.

Создайте в корневой папке web-сервера postinstall/config файл со стандартным приглашением входа. Там можно размещать все, что хотите, но помните, что ее содержимое будет видно всем, кто пытается войти! Сохраните файл как баннер и поместите его в свою папку /postinstall/config/.

Сейчас, когда установка выполнена, вы можете занести это в скрипт, чтобы потом делаь ее одной командой (или поместите ее в раздел %post, если нужно сделать несколько конфигураций kickstart). Сохраните скрипт в /var/www/html/postinstall/secure.sh: 

cd /etc/
wget http://url to web server/postinstall/config/banner
cd ssh
mv sshd_config sshd_config.old
wget http://url to web server/postinstall/config/sshd_config
service sshd restart # Restart sshd for changes to take effect

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

cd /tmp
wget http://your web server ip address/postinstall/secure.sh
chmod +x secure.sh
./secure.sh

Тот же принцип можно использовать для копирования любых своих файлов: например, скопировать пользовательский ntpd.conf в /etc/, а затем выполнить ntpd start и запустить службу ntp. Сейчас самое время напомнить вам об еще одном полезном с нашей точки зрения элементе: команде chkconfig, которой мы коснулись в прошлый раз.

Ею можно управлять службами на различных уровнях запуска. Примером, как и выше, служит автоматический запуск службы ntp на всех уровнях. Это сработает со многими службами, которые устанавливаются с носителя RH/Centos.

Добавьте в %post следующую команду (или скрипт оболочки, если вы последовали моему совету: один скрипт – одна цель): 

chkconfig --level 35 ntpd on

Она определит, на каких уровнях запускается ntpd. Команда chkconfig --list любезно выдаст вам все службы и используемые ими уровни запуска.

Еще одна полезная сторона раздела %post – он пригоден для удаления нежелательных пользователей, добавленных по умолчанию в процессе установки. Очевидные примеры таковых – games, uucp и sendmail.

Воспользуйтесь командной строкой, как будто вы удаляете их обычным образом, а затем добавьте это в скрипт. Например: 

userdel -g uucp games mail

Добавить пользователя не сложнее. По сути, почти любую неинтерактивную команду можно включить в раздел %post. Просто поместите ее в скрипт, как мы проделали только что, только поменяйте имя и команды.

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

Чтобы меньше пришлось выполнять cd и chmod для ваших файлов, а затем выполнять и их, все это можно сделать глобально.

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

cd /tmp
wget http://url to web server/postinstall/scripts/guest.sh
wget http://url to web server/postinstall/secure.sh
wget http://url to web server/postinstall/scripts/repo.sh
wget http://url to web server/postinstall/scripts/sysconf.sh
chmod +x *.sh
file in /tmp
do
./*.sh
done

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

По умолчанию вы можете ничего не найти в списке, но это не проблема. Можно создать cron, просто выводя командой echo то, что мы намереваемся сделать командой. (Если вы собрались сделать crontab одинаковым на всех машинах, можете просто добавить его к тому скрипту, что мы использовали ранее, поменяв имена файлов и расположений.)

Также можно установить новых пользователей. Это базовый пример (его следует использовать для системных учетных записей, а не пользователей. Если получается, что вы создаете на разных компьютерах множество пользователей с одним и тем же именем и целями, призадумайтесь об установке LDAP), однако добавление пользователей может стать весьма полезным, если вы хотите выполнять службы для учетных записей с меньшими привилегиями.

Я также предложил бы вам использовать команду echo для расселения и изменения файлов. Пример этого столь же прост, как и добавление хостов прямо в файл hosts без использования DNS. Чтобы проделать это еще раз, просто выполните следующую команду 

echo “192.168.1.3 application.mydomain.com” >> /etc/hosts.

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

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF146:tut9&oldid=15355»
Персональные инструменты
купить
подписаться
Яндекс.Метрика