Практикум по администрированию программного обеспечения. Лабораторный практикум

Лабораторный практикум

Контрольные вопросы

1.Какие задачи необходимо решать с помощью скриптов.

2.Структура скриптов.

3.Способы запуска скриптов.

4.Технология тестирования скриптов.

5.Сравнение возможностей скриптов и удобства разработки в различных ОС.

Литература : 1, 2, 3, 4.

6. ИССЛЕДОВАНИЕ ДЕМОНАПЛАНИРОВЩИКА ЗАДАЧ CRON

Цель – научиться выполнять задачи по расписанию.

Формируемые компетенции или их части: ПК-12; ПК-37.

Теоретическая часть

Cron – классический демон-планировщик задач в UNIX-подоб- ных операционных системах, использующийся для периодического выполнения заданий в определённое время. Регулярные действия описываются инструкциями, помещенными в файлы crontab и в специальные директории. В системах на базе systemd фактически замещен встроенным в него механизмом systemd.timer.

Утилита crontab управляет доступом пользователя к демону cron (см. cron(1M)) путем копирования, создания, выдачи содержимого и удаления файлов crontab, таблиц заданий. При вызове без опций, crontab копирует указанный файл или стандартный входной поток (если файл не указан) в каталог, в котором хранятся пользовательские таблицы заданий cron.

Контроль доступа к crontab

Доступ пользователя к crontab разрешен, если:

–имя пользователя указано в файле /etc/cron.d/cron.allow;

–файл /etc/cron.d/cron.allow не существует и имя пользователя не указано в файле /etc/cron.d/cron.deny.

Доступ пользователя к crontab не разрешен, если:

–файл /etc/cron.d/cron.allow существует и имя пользователя в

нем не указано.

– файл /etc/cron.d/cron.allow не существует и имя пользователя указано в файле /etc/cron.d/cron.deny.

31

Практикум по администрированию программного обеспечения

–ни один из упомянутых файлов не существует и пользователь не получил привилегию solaris.jobs.user через роль.

Следует учитывать, что правила разрешения и запрещения выполнения заданий применимы к пользователю root только если существуют файлы allow/deny.

В файлах allow/deny надо задавать по одному имени пользователя в строке.

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

–минуту (0–59),

–час (0–23),

–день месяца (1–31),

–месяц года (1–12),

–день недели (0–6, причем 0 = воскресенье).

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

Шестое поле в строке файла crontab – строка, выполняемая командным интерпретатором в указанные моменты времени. Символ % (процент) в этом поле, если он не замаскирован \ (обратной косой), преобразуется в символ новой строки.

Только первая строка (до символа % или до конца строки) поля команды выполняется командным интерпретатором. Другие строки передаются команде как стандартный входной поток. Любая строка, начинающаяся символом #, считается комментарием и игнорируется. Файл не должен содержать пустых строк.

Командный интерпретатор вызывается из начального каталога соответствующего пользователя с аргументом arg0, равным sh. Пользователи, желающие, чтобы был выполнен их файл .profile, должны явно это указать в команде в файле crontab. Демон cron предоставляет каждому командному интерпретатору стандартную среду, задавая переменные HOME, LOGNAME, SHELL(=/bin/sh), TZ и PATH. Стандартное значение переменной PATH для пользовательских заданий cron – /usr/bin, а для заданий cron пользователя root – /usr/sbin:/usr/bin. Стандартное значение переменной PATH можно задать в файле /etc/default/cron; см. cron(1M).

Если стандартный выходной поток и стандартный поток ошибок команд не перенаправлены, любые сгенерированные резуль-

32

Лабораторный практикум

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

Опции. Поддерживаются следующие опции:

–e – редактирует копию файла crontab текущего пользователя или создает пустой файл для редактирования, если соответствующего файла crontab не существует. Когда редактирование завершается, файл устанавливается в качестве пользовательского файла crontab. Если задано имя пользователя, реадктируется файлcrontab этого, а не текущего пользователя; это может сделать только пользователь с привилегией solaris.jobs.admin. Переменная среды EDITOR задает редактор, вызываемый при указании опции -e. Стандартным редактором является ed(1). Учтите, что все задания в файлеcrontab должны создаваться с помощью утилиты crontab; не стоит добавлять задания, просто редактируя файл crontab, поскольку демон cron не будет знать об изменениях, выполненных таким способом;

–l – выдает файл crontab вызвавшего пользователя. Только пользователь с привилегией solaris.jobs.admin может указывать имя пользователя после опций -r или -l для удаления или просмотра файла crontab другого пользователя;

–r – удаляет пользовательский файл crontab из каталога зада-

ний cron.

ПРИМЕРЫ

Пример 1. Удаление core-файлов

Это задание удаляет файлы core каждый день в 3:15 утра:

15 3 * * 1-5 find $HOME -name core 2>/dev/null | xargs rm -f

Пример 2. Посылка позвдравления с днем рождения

0 12 14 2 * mailx john%Happy Birthday!%Time for lunch.

Пример 3. Задание дней месяца и дня недели Следующее задание

0 0 1,15 * 1

будет выполнять команду 1 и 15 числа каждого месяца, а также по понедельникам.

Чтобы задать дни выполнения только одним способом, в другом поле надо поставить *. Например, задание:

0 0 * * 1

приведет к выполнению команды только по понедельникам. Переменные среды. Описание следующих переменных LC_

CTYPE, LC_MESSAGES иNLSPATH, влияющих на работу команды crontab, см. на странице справочного руководства environ(5).

Editor. Задает редактор, вызываемый при задании опции -e. Стандартно вызывается редактор ed(1). Если установлены переменные среды EDITOR и VISUAL, редактор определяется значением переменной VISUAL.

33

Практикум по администрированию программного обеспечения

Статус выхода. Команда завершается со следующими статусами выхода:

0Успешное выполнение. >0Произошла ошибка.

Практическое задание

1.Задокументировать алгоритм создания задач в планировщике заданий.

2.Создать правило – создавать файл в домашнем каталоге каждую минуту.

3.Реализовать запуск скрипта резервного копирования из работы 5 раз в день.

4.Изменить скрипт: в качестве имени папки использовать текущее время, а не дату. Добавить в планировщик задачу резервного копирования папки каждые пять минут.

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

Контрольные вопросы

1.Планировщики в различных ОС.

2.Задачи, решаемые с помощью планировщиков.

3.Технология администрирования планировщика CRON.

4.Архивирование и восстановление данных с помощью планировщика.

5.Многопользовательский сценарий работы с CRON.

Литература : 1, 2, 3, 4.

7. ИССЛЕДОВАНИЕ МЕЖСЕТЕВОГО ЭКРАНА NETFILTER ДЛЯ LINUX

Цель – познакомиться с возможностями межсетевых экранов в Linux системах, научиться администрировать межсетевые экраны.

Формируемые компетенции или их части: ПК-37, ПК-40.

Теоретическая часть

Изначально разработка netfilter и iptables шла совместно, поэтому в ранней истории этих проектов есть много общего.

34

Лабораторный практикум

Предшественниками iptables были проекты ipchains (применялась для администрирования фаервола ядра Linux версии 2.2) и ipfwadm (аналогично для ядер Linux версий 2.0). Последний был основан на BSD-утилите ipfw.

iptables сохраняет идеологию, ведущую начало от ipfwadm: функционирование фаервола определяется набором правил, каждое из которых состоит из критерия и действия, применяемого к пакетам, подпадающим под этот критерий. В ipchains появилась концепция цепочек – независимых списков правил. Были введены отдельные цепочки для фильтрации входящих (INPUT), исходящих (OUTPUT) и транзитных (FORWARD) пакетов. В продолжении этой идеи, в iptables появились таблицы – независимые группы цепочек. Каждая таблица решала свою задачу – цепочки таблицы filter отвечали за фильтрацию, цепочки таблицы nat – за преобразование сетевых адресов (NAT), к задачам таблицы mangle относились прочие модификации заголовков пакетов (например, изменение TTL или TOS). Кроме того, была слегка изменена логика работы цепочек: в ipchains все входящие пакеты, включая транзитные, проходили цепочку INPUT. В iptables через INPUT проходят только пакеты, адресованные самому хосту.

Такое разделение функциональности позволило iptables при обработке отдельных пакетов использовать информацию о соединениях в целом (ранее это было возможно только для NAT). В этом iptables значительно превосходит ipchains, так iptables может отслеживать состояние соединения и перенаправлять, изменять или отфильтровывать пакеты, основываясь не только на данных из их заголовков (источник, получатель) или содержимом пакетов, но и на основании данных о соединении. Такая возможность фаервола называется stateful-фильтрацией, в отличие от реализованной в ipchains примитивной stateless-фильтрации (подробнее о видах фильтрации см. статью о фаерволах). Можно сказать, что iptables анализирует не только передаваемые данные, но и контекст их передачи, в отличие от ipchains, и поэтому может принимать более обоснованные решения о судьбе каждого конкретного пакета. Более подробно о stateful-фильтрации в netfilter/iptables см. w:Netfilter#Механизм определения состояний.

В будущем, разработчики netfilter планируют заменить iptables на nftables – инструмент нового поколения, пока находящийся в ранней стадии разработки.

Ключевыми понятиями iptables являются следующие. Правило – состоит из критерия, действия и счетчика. Если па-

кет соответствует критерию, к нему применяется действие, и он

35

Практикум по администрированию программного обеспечения

учитывается счетчиком. Критерия может и не быть – тогда неявно предполагается критерий «все пакеты». Указывать действие тоже не обязательно – в отсутствие действия правило будет работать только как счетчик.

Критерий – логическое выражение, анализирующее свойства пакета и/или соединения и определяющее, подпадает ли данный конкретный пакет под действие текущего правила.

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

Счетчик – компонент правила, обеспечивающий учет количества пакетов, которые попали под критерий данного правила. Также счетчик учитывает суммарный объем таких пакетов в байтах.

Цепочка – упорядоченная последовательность правил. Цепочки можно разделить на пользовательские и базовые.

Базовая цепочка – цепочка, создаваемая по умолчанию при инициализации таблицы. Каждый пакет, в зависимости от того, предназначен ли он самому хосту, сгенерирован им или является транзитным, должен пройти положенный ему набор базовых цепочек различных таблиц. Схема следования пакетов приведена на рисунке. Кроме того, базовая цепочка отличается от пользовательской наличием «действия по умолчанию» (default policy). Это действие применяется к тем пакетам, которые не были обработаны другими правилами этой цепочки и вызванных из нее цепочек (см. переходы). Имена базовых цепочек всегда записываются в верхнем реги-

стре (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING).

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

Таблица – совокупность базовых и пользовательских цепочек, объединенных общим функциональным назначением. Имена таблиц (как и модулей критериев) записываются в нижнем регистре, так как в принципе не могут конфликтовать с именами пользовательских цепочек. При вызове команды iptables таблица указывается в формате -t имя_таблицы. При отсутствии явного указания, используется таблица filter. Более подробно таблицы будут рассмотрены ниже.

36

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

Схема прохождения трафика по цепочкам представлена на рис. 7.1.

37

Практикум по администрированию программного обеспечения

Рис. 7.1. Схема прохождения таблиц

Кроме основного функционала, Iptables способен подгружать дополнительные модули, для дополнительной обработки. Одним из таких модулей является модуль обработки состояний пакета state. Он позволяет указывать состояние пакета:

38

2. Консольная команда iptables принимает в качестве параметров описание одного правила. В базовом варианте для загрузки правил подразумевается создание скрипта вида:

#!/bin/bash

#rc.firewall – load iptables rules PROG=’/sbin/iptables’

#clear all chains tables $PROG -F

#filter table

$PROG -A INPUT -t filter -p TCP -s 80.32.5.7/32 -d 0.0.0.0 –dport 80 -j ACCEPT

…

Команда принимает следующие основные параметры для работы с цепочками:

39

Практикум по администрированию программного обеспечения

Для параметров используются критерии:

Примеры:

iptables -P INPUT ACCEPT -t filter

iptables-AINPUT-tfilter-pTCP-s192.168.1.1/32-d192.168.2.0/24 --dport 25 -j DROP

iptables -APOSTROUTING -t nat -pALL -s 192.168.1.0/24 -j SNAT --to-source 192.168.1.5

iptables -N mychain -t filter

iptables -A OUTPUT -t filter -d 193.19.64.11 --dport 21 -j mychain iptables -A mychain -t filter -s 192.168.1.0/24 -j ACCEPT iptables -A mychain -t filter -s 192.168.2.0/24 -j REJECT

iptables -A FORWARD -t filter -m mac --mac-source 11:22:33:44:55:66 -j ACCEPT

iptables -A INPUT -t filter -p TCP -d 192.168.1.0/32 --dport 21 -m state --state ESTABLISHED,RELATED -j ACCEPT

Практическое задание

1.Описать алгоритм администрирования межсетевого экрана.

2.Разрешить все исходящие соединения по всем интерфейсам.

40