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

Проблема в том, достоверность ответа DNS-сервера никак не проверяется, это означает, что в случае взлома DNS сервера (и перенаправления его на ложные DNS сервера), подделки DNS записи, отравлении кэша DNS (DNS cache poisoning), можно отправить пользователя на произвольный IP адрес, причем пользователь будет находится в полной уверенности, что он работает с легитимным сайтом или сервисом. Этими методиками широко используют злоумышленники, перенаправляя пользователей на сайты, содержащие вредоносные коды или собирая их личные данные (пароли, номера кредиток и т.п.) с помощью т.н. pharming атак.

Зачем нужна технология DNSSEC

DNS Security Extensions (DNSSEC) – технология, предназначена для повышения безопасности службы DNS за счет использования криптографических подписей, позволяющих однозначно удостоверится в подлинности информации, полученной от DNS сервера. Т.е. все запросы и ответы DNS сервера с поддержкой DNSSEC должны обладать цифровой подписью, верность которой может проверить клиент с помощью открытого ключа. Эти цифровые подписи создаются при подписывании зоны (применения к ней DNSSEC).

Упрощенно механизм проверки DNSSEC работает так: клиент отправляет запрос на DNS сервер, сервер возвращает DNS ответ с цифровой подписью. Т.к. клиент обладает открытым ключом центра сертификации, подписавшего записи DNS, он может расшифровать подпись (хэш-значение) и проверить ответ DNS. Для этого и клиент и сервер DNS должны быть настроены на использование одного якоря доверия (trust anchor). Trust anchor – предварительно настроенный открытый ключ, связанный с конкретной зоной DNS. Если DNS сервер поддерживает несколько зон, то может использоваться несколько якорей доверия.

Важно отметить, что основное предназначение DNSSEC – защита от подделки и модификации DNS-запросов и ответов. Но сами передаваемые по сети данные не шифруются (хотя конфиденциальность передаваемых DNS данных и может быть обеспечено с помощью шифрования, но это опционально и не является основной целью DNSSEC).

Основные компоненты DNSSEC определены в следующих стандартах RFC:

  • RFC 4033
  • RFC 4034
  • RFC 4035

DNSSEC в системах Windows

Поддержка технология DNSSEC появилась еще в Windows Server 2008 R2 и Windows 7. Однако из-за сложности и неочевидности настроек, широкого распространения она не получила. Свое дальнейшее развитие DNSSEC получила в Windows Server 2012, в котором функционал DNSSEC был существенно расширен, и предполагает возможность настройки через графический интерфейс.

В этой статье мы опишем базовую установку и настройку DNSSEC на базе DNS сервера с ОС Windows Server 2012, создадим подписанную зону и точки доверия.

Установка и настройка DNSSEC в Windows Server 2012

Создадим новую DNS зону dnssec.contoso.com и добавим в нее одну A запись сервера SRV12 с адресом 192.168.1.14.

Примечание . В Windows 8/2012 вместо утилиты nslookup для получения информации с DNS сервера лучше воспользоваться Powershell командлетом Resolve-DnsName.

Resolve-DnsName srv12.dnssec.contoso.com –Server SRV12-SUB-CA –DnssecOk

Т.к. зона не подписана, запрос не вернет записи RRSIG.

Подпишем цифровым сертификатом внутреннюю DNS зону dnssec.contoso.com. Для этого в консоли DNS щелкните правой кнопкой по зоне и выберите пункт DNSSEC->Sign the Zone .

В появившемся мастере Zone Signing Wizard оставьте все параметры по умолчанию (Use default settings to sign the zone) -> Next -> Next -> Finish.

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

  • RRSIG (Resource Read Signature) — подпись ресурсной записи
  • DNSKEY (A Public Key) – хранит публичную часть ключа и его идентификаторы
  • DS (Delegation Signer) – содержит хэш доменного имени наследника и его ключа KSK
  • NSEC (Next Secure) и NSEC3 (Next Secure 3) – используется для надежной защиты от spoofing атак

После того, как зона подписана, открытый ключ будет сохранен в файле %windir%\system32\dns\keyset-dnssec.

Импортируем в DNS открытый ключ зоны (тот самый якорь доверия), перейдя в консоли DNS в раздел Trust Point, выбрав import -> DNSKEY, и указав путь к файлу keyset-dnssec.

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

В результате импорта ключа в разделе Trust Points -> dnssec появится два ключа типа DNSKEY (один ключ активный, другой — standby).

В Windows Server 2012 возможно автоматически реплицировать ключи якорей доверия (Trust Anchors) по всем контролерам домена в лесу, обслуживающем данную зону DNS. Для этого в свойствах нужной зоны (dnssec) на вкладке Trust Anchor включите опцию Enable the Distribution of Trust Anchors for this zone и сохраните изменения.

Попробуем еще раз опросить данную зону с клиента.

Как мы видим, в ответе DNS сервера есть информации об RRSIG записи и цифровой подписи.

Настройка клиентов WIndows на использование DNSSEC

Чтобы заставить клиентов на ОС Windows принудительно использовать только «безопасные» (DNSSEC) запросы, т.е. принимать DNS данные только в том случае, если их цифровая подпись верна, необходимо с помощью GPO задействует политику NRPT (Name Resolution Policy Table).

Для этого в разделе GPO Computer Configuration -> Polices -> Windows Settings -> Name Resolution Policy на вкладке DNSSEC включите опции:

  • Enable DNSSEC in this rule
  • Require DNS clients to check that name and address data has been validated by the DNS server

Осталось назначить политику на нужную OU. После применения политики убедимся, что клиент настроен на использование «безопасного» DNS:

Get-DnsClientNrptPolicy

Значение DNSSecValidationRequired=True , т.е. на клиенте требуется обязательная валидация ответов DNS.

В том случае, если полученный от DNS сервера ответ не будет подписан, или будет подписан неверным сертификатов, команда вернет ошибку Unsecured DNS packet .

DNSSEC для внешних зон

Чтобы DNS сервер требовал обязательной проверки DNSSEC для внешних зон, нужно в его свойствах на вкладке Advanced включить опцию Enable DNSSEC validation for remote responses .

Импортировать якоря доверия корневых зон можно вручную (описано выше), либо с помощью команды:

Dnscmd /RetrieveRootTrustAnchors

Совет . Для корректной работы DNSSEC необходимо внести ряд изменений в межсетевые экраны:

  1. Открыть в обе стороны порт 53 порт протоколов TCP и UDP
  2. Т.к. размер данных в пакете DNSSec превышают 512 байт, необходимо разрешить прохождение DNS пакетов более 512 байт по UDP и TCP

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

Ключи шифрования протокола DNSSEC обновляются впервые с момента запуска системы 15 июля 2010 года, когда была подписана корневая зона, иногда именуемая «точкой», то есть зона, стоящая над доменами верхнего уровня, такими как.com., .ru., .org., .net. и другими (в интерфейсах браузеров замыкающая точка обычно опускается). Решение о перевыпуске «ключа подписи ключей», Key Signing Key или KSK, для корневой зоны несколько раз откладывалось, изначально планировалось, что корневая зона в целях безопасности будет заново подписываться каждые пять лет - первая замена ключа была запланирована на 2015 год. Опасения корпорации ICANN вызваны тем, что не все серверы DSN с поддержкой DNSSEC переключатся на использование нового ключа шифрования: единожды сконфигурированные серверы всё это время могли работать корректно, но их владельцы могли не учесть возможность обновления KSK.

Простой сервис настройки DNSSEC для владельцев доменов из российского сегмента, то есть в зонах ru, «рф» и su, предоставляют только три регистратора, которые также владеют и собственными серверами DNS: nic.ru , reg.ru и webnames.ru . Пока особой популярностью протокол не пользуется: из 5,6 млн российских доменов, по статистике регулирующего российские зоны «Координационного центра», число доменов с поддержкой DNSSEC на сентябрь 2018 года не превысило 3 000 штук, хотя в их число входят наиболее крупные и популярные ресурсы рунета. В тоже время наиболее популярный среди владельцев российских доменов сервис «Яндекс Коннект» не поддерживает DNSSEC, хотя «Яндекс.DNS» для домашних пользователей поддержку безопасного протокола обеспечивает. В глобальном доменном пространстве доменов, работающих по DNSSEC, на порядки больше: по данным statdns , из 135 млн доменов в одной только зоне com доменных имён с DNSSEC почти миллион.

В комментариях UPgrade все три российских регистратора, поддерживающих DNSSEC, заявили о том, что готовы к смене KSK, в настоящий момент они работают со старым ключом в активном режиме, а с новым ключом, открытая часть которого была опубликована ICANN ещё 11 сентября 2017 года, - в пассивном режиме. По команде ICANN регистраторы готовы поменять статус ключей и не ожидают сбоев. Крупнейшие держатели собственных серверов разрешения доменных имён не из числа регистраторов, «Ростелеком», «Мегафон», «Билайн» и МТС, в комментариях РБК заявили, что также готовы к смене ключа. Однако приведёт ли смена KSK к сбоям у владельцев менее крупных серверов DNS, например, у провайдеров в небольших городах, предугадать невозможно, хотя корпорация ICANN активно работает с техническими администраторами провайдеров, операторами связи и другими компаниями, работающими с интернет–инфраструктурой напрямую.

Служба DNS или Domain Name System была разработана практически одновременно с введением доменов в 1980–х годах. При обращении к доменному имени (например, сайт) через службу DNS интернет–провайдер находит IP–адрес (например, 87.236.16.85), соответствующий доменному имени. Владельцы доменов указывают на собственных DNS–серверах (например, ns1.beget.com) так называемые «ресурсные записи» (например, * A 87.236.16.85). Другие серверы DNS через некоторое время копируют эти записи и создают из них кэш, чтобы каждый раз не обращаться к исходному серверу. До введения DNSSEC серверы DNS безоговорочно доверяли информации друг друга, что делало их уязвимыми перед попытками злоумышленников «отравить кэш», то есть предоставить «доверчивому» серверу DNS запись с подменой IP–адреса на адрес злоумышленника. Таким образом посетители крупных ресурсов, онлайн–банков, социальных сетей, поисковых служб и прочих сайтов могли быть перенаправлены на поддельный ресурс.

Чтобы исключить отравление кэша DNS и другие угрозы были разработаны «расширения безопасности DNS», DNS Security Extensions или DNSSEC. Внедрение расширенного протокола замедлялось из–за его требовательности к вычислительным мощностям серверов и высокой нагрузки на сети. Упрощённый протокол DNSSEC–bis с обратной совместимостью с системой DNS ввёл в действие каскад не столь требовательных к вычислениям электронных сертификатов от корневой зоны до индивидуальных доменов, которые DNS–серверы могли бы на лету проверять на подлинность при каждом запросе. KSK корневой зоны требует периодического обновления: созданный в 2010 году 1024–битный ключ KSK–2010 в 2017 году был усложнён до 2048–битного KSK–2017 в ответ на повышение мировых вычислительных мощностей, которых могло бы хватить для подбора шифра.

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

Кроме того, NSEC3 запись имеет поле флагов, которого нет у NSEC. На данный момент определен только один флаг - OPT-OUT, благодаря которому существует возможность подписывать не всю зону (что при больших размерах может быть весьма длительным процессом), а только те доменные имена, для которых есть DS записи.
С одной стороны OPT-OUT позволяет сильно сократить время подписи, однако при его использовании, наличие у злоумышленника доступа к файлу зоны позволяет ему добавить незащищенную запись, которая в дальнейшем может доставить проблемы.

Механизм работы
Допустим мы хотим узнать адрес test.bar.example.com:
  1. Мы запрашиваем доменное имя у резолвера;
  2. Резолвер выставляет бит DO и запрашивает test.bar.example.com у корневого сервера;
  3. Резолвер знает, что корневая доменная зона подписана - у него указан ключ или хэш ключа для нее (так называемый trust-anchor), поэтому он запрашивает у корневого сервера DNSKEY записи для корневой зоны и сверяет полученное с имеющимся;
  4. Корневой сервер не знает такого доменного имени, да и вообще максимум что ему известно - на каких серверах располагается зона com, он и сообщает адреса этих серверов нашему резолверу вместе с подписанной DS записью для зоны com;
  5. Резолвер валидирует DS запись полученным и проверенным ZSK ключом корневой зоны;
  6. Теперь резолвер знает, что зона com подписана, так что он спрашивает у ее DNS сервера DNSKEY и валидирует их, после чего интересуется про bar.example.com. Естественно, что сервер зоны com про таких не знает, ему только известно, что зона example.com живет на ns.example.com и ns1.example.com, именно это он и отвечает резолверу вместе с - да-да - DS записью;
  7. Так резолвер выстроил цепочку доверия до example.com, где он узнает серверы имен зоны bar.example.com и ее DS;
  8. В конце концов резолвер итеративно узнает адреса DNS серверов, отвечающих за bar.example.com, идет к ним и наконец-то получает желаемое, валидирует всю информацию и отдает нам адресную запись, выставив в ответе бит AD.
При невозможности что-то провалидировать резолвер вернет servfail.
Оказываемые эффекты
  1. Исходящий трафик авторитетного DNS сервера увеличивается примерно в 4 раза;
  2. Размер файла зоны после подписи (без OPT-OUT) вырастает в 6-7 раз;
  3. Увеличение длины ключа приводит к заметному снижению qps резолвера, на авторитетный сервер влияет в меньшей степени;
  4. Наоборот действует увеличение кол-ва итераций при использовании NSEC3;
  5. DNSSec приводит к значительному увеличению DNS ответа и, следовательно, необходимо чтобы все сетевое оборудование корректно работало с DNS пакетами более 512 байт.

Зачем это нужно

Это сложный вопрос. Во-первых, надо учитывать создаваемые эффекты; во-вторых, требуется организовать надежное хранилище для ключей; в-третьих, следить за ротацией ключей; в-четвертых, следить за сроком годности подписей; в-пятых, DNSSec усиливает эффект amplified ddos.
Все это является платой за то, чтобы быть уверенным в информации, получаемой от авторитетных DNS серверов. Сейчас, правда, сообщество придумывает что еще можно включить в DNSSec, чтобы его можно было монетизировать, а некоторые и вовсе задаются весьма смелыми и интересными вопросами, например Phil Regnauld, член научного совета AFNIC, поинтересовавшийся «Will DNSSEC bring down the certificate industry?» на семинаре этого совета.

We all know that DNS is a protocol which resolves domain names to IP addresses, but how do we know the authenticity of the returned IP address? It is possible for an attacker to tamper a DNS response or poison the DNS cache and take users to a malicious site with the legitimate domain name in the address bar. DNS Security Extensions (DNSSEC) is a specification which aims at maintaining the data integrity of DNS responses. DNSSEC signs all the DNS resource records (A, MX, CNAME etc.) of a zone using PKI (Public Key Infrastructure). Now DNSSEC enabled DNS resolvers (like Google Public DNS) can verify the authenticity of a DNS reply (containing an IP address) using the public DNSKEY record.

DNSSEC Resource Records

A Resource Record (RR) contains a specific information about the domain. Some common ones are A record which contains the IP address of the domain, AAAA record which holds the IPv6 information, and MX record which has mail servers of a domain. A complete list of DNS RRs can be found .

Likewise DNSSEC too requires several RRs.

  • DNSKEY Holds the public key which resolvers use to verify.
  • RRSIG Exists for each RR and contains the digital signature of a record.
  • DS - Delegation Signer – this record exists in the TLD"s nameservers. So if example.com was your domain name, the TLD is "com" and its nameservers are a.gtld-servers.net. , b.gtld-servers.net. up to m.gtld-servers.net. . The purpose of this record is to verify the authenticity of the DNSKEY itself.

Setup Environment

Domain Name: example.com

I used a real .COM domain to do this, but have replaced it with example.com for this article.

Master Nameserver:
IP Address: 1.1.1.1
Hostname: master.example.com
OS: Debian 7

Slave Nameserver:
IP Address: 2.2.2.2
Hostname: slave.example.com
OS: CentOS

File locations and names

The names and locations of configuration and zone files of BIND different according to the Linux distribution used.

Debian/Ubuntu

Service name:
bind9
Main configuration file:
/etc/bind/named.conf.options
Zone names file:
/etc/bind/named.conf.local
Default zone file location:
/var/cache/bind/

CentOS/Fedora

Service name:
named
Main configuration and zone names file:
/etc/named.conf
Default zone file location:
/var/named/

These may change if you"re using bind-chroot . For this tutorial, I"ve used Debian for the Master NS and CentOS for the Slave NS, so change it according to your distribution.

DNSSEC Master Configuration

Enable DNSSEC by adding the following configuration directives inside options{ }

nano /etc/bind/named.conf.options

Dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto;

It is possible that these are already added in some distributions. Navigate to the location of your zone files.

Cd /var/cache/bind

Create a Zone Signing Key(ZSK) with the following command.

Dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE example.com

The first tool is a simple one, while the second gives you a visual representation of things. Here is a screenshot from the first tool.

Notice the lines I"ve marked. The first one mentions the Key tag value (62910) of the DS record while the second one key id (40400) of the DNSKEY record which holds the ZSK (Zone Signing Key).

Modifying Zone Records

Each time you edit the zone by adding or removing records, it has to be signed to make it work. So we will create a script for this so that we don"t have to type long commands every time.

Root@master# nano /usr/sbin/zonesigner.sh #!/bin/sh PDIR=`pwd` ZONEDIR="/var/cache/bind" #location of your zone files ZONE=$1 ZONEFILE=$2 DNSSERVICE="bind9" #On CentOS/Fedora replace this with "named" cd $ZONEDIR SERIAL=`/usr/sbin/named-checkzone $ZONE $ZONEFILE | egrep -ho "{10}"` sed -i "s/"$SERIAL"/"$(($SERIAL+1))"/" $ZONEFILE /usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N increment -o $1 -t $2 service $DNSSERVICE reload cd $PDIR

Save the file and make it executable.

Root@master# chmod +x /usr/sbin/zonesigner.sh

Whenever you want to add or remove records, edit the example.com.zone and NOT the .signed file . This file also takes care of incrementing the serial value, so you needn"t do it each time you edit the file. After editing it run the script by passing the domain name and zone filename as parameters.

Root@master# zonesigner.sh example.com example.com.zone

You do not have to do anything on the slave nameserver as the incremented serial will ensure the zone if transferred and updated.

Securing the DNSSEC setup from Zone Walking

Zone Walking is a technique used to find all the Resource Records of a zone by querying the NSEC (Next-Secure) record. NSEC3 was released which "hashed" this information using a salt. Recall the dnssec-signzone command in which we specified a -3 option followed by another elaborate command to generate a random string. This is the salt which can be found using the following dig query.

# dig NSEC3PARAM example.com. @master.example.com. +short 1 0 10 7CBAA916230368F2

All this makes zone walking difficult but not impossible. A determined hacker using rainbow tables can break the hash, though it"ll take a long time. To prevent this we can recompute this salt at regular intervals, which makes a hacker"s attempt futile as there is a new salt before he/she can find the hash with the old salt. Create a cron job to do this for you using the zonesigner.sh script we created previously. If you run the cronjob as root you don"t have to worry about file ownership. Or else make sure the user under whom you"re placing the cron has write permission on the zone directory and read permission on the private keys (Kexample.com.*.private).

Root@master:~# crontab -e 0 0 */3 * * /usr/sbin/zonesigner.sh example.com example.com.zone

This will sign the zone every 3 days and as a result a new salt will be generated. You"ll also receive an email containing the output of the dnssec-signzone command.

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

Задача: Бэкап данных в локальную директорию и на отдельный сервер, с использованием минимума стороннего ПО, логированием и оповещением администратора в jabber при сбоях. Все основные функции большинства ПО для автоматического бэкапа, но без установки оного, а следовательно без его багов (что, собственно, и привело к подобной идее).

А теперь к делу.

Для начала создадим и откроем скрипт
nano backup-script
Теперь в скрипте добавим строку
#!/bin/bash
Объявим некоторые переменные.
TN - TASKNAME - имя задания.Используется для вывода в лог и определения названия файла.
Так как заданий несколько (ежемесячное, еженедельное, ежедневное) и писать на каждый случай скрипт было лень, я создал универсальный, в котором надо просто раскомментить нужные строки. Наименование заданий писать надо без пробелов, желательно в латинице, если не хотите проблем с кодировкой и неправильными параметрами команд.
TN=docs-monthly
#TN=docs-weekly
#TN=docs-daily
OF - Output File - имя выходного файла. Получается из переменной TN, то есть имени задания.
OF=$TN.tar.gz
Объявляем переменную с путем к файлу лога, и далее все сообщения об ошибках и остальном будем выводить в лог.
LOGFILE=/var/log/backup.log
Сделаем запись в лог о начале бэкапа (дата, время, имя задания)
echo >>$LOGFILE echo "=====================================================" >>$LOGFILE echo "$(date +"%d-%b-%Y %R")" >>$LOGFILE echo "Задание \"$TN\" запущено..." >>$LOGFILE
Есть проблема в том что если указывать в параметрах команд (напр. tar) имена каталогов с пробелами, скрипт срабатывает с ошибкой. Решение найдено на просторах интернета - операционная система linux использует пробел в качестве стандартного разделителя параметров команды. Переопределим стандартный разделитель (хранится в переменной $IFS) отличным от пробела, например \n – знаком переноса строки.
Запоминаем старое значение стандартного разделителя
OLD_IFS=$IFS
Заменяем стандартный разделитель своим
IFS=$"\n"
SRCD - SouRCe Directory - каталог с данными для бэкапа
Теперь можно перечислять несколько каталогов, разделителем будет перенос строк как мы сами указали строкой выше
SRCD="/mnt/source/folder_1 /mnt/source/folder_2 /mnt/source/folder_N"
TGTD - TarGeT Directory - каталог в который будут складываться бэкапы
TGTD="/var/backups/"
Естественно мы понимаем что хранить важные бэкапы только на источнике как минимум легкомысленно. Поэтому оставим копию и на удаленном ресурсе, который будем отдельно монтировать с помощью mount и fstab. Сразу поясню почему я использовал mount и fstab, а не один mount - я монтирую этот каталог и в других своих скриптах, а как сказал один из знакомых программистов - хороший программист не будет писать один и тот же код дважды (как-то так, дословно не помню, но надеюсь смысл донес).
TGTD2="/mnt/archive/"
Сам процесс архивирования в варианте "Создать новый архив"
tar -czf $TGTD$OF $SRCD &>>$LOGFILE
и в варианте "Обновить файлы в старом архиве"
tar -u -f $TGTD$OF $SRCD &>>$LOGFILE
Во втором случае лучше вместо $OF использовать конктретное имя файла потому что у меня например ежедневно апдэйтится еженедельный архив, а их $TN (имена задания) не совпадают, соответственно и $OF.

В переменной "?" ханится статус выполнения последней команды. Сохраним его, чтобы воспользоваться позже.
STATUS=$?
Возвращаем стандартный разделитель к исходному значению
IFS=$OLD_IFS
Теперь добавим условие - если процесс упаковки в архив tar закончился с ошибкой, отправляем сообщение админу, удаляем неудачный файл бекапа. Иначе продолжаем дальше - монтируем сетевую шару и кидаем в нее копию архива. После каждой операции проверяем результат выполнения, пишем логи, и либо продолжаем, либо извещаем админа и прерываем процедуру.
if [[ $STATUS != 0 ]]; then rm $TGTD$OF &>>$LOGFILE echo "###########################################" >>$LOGFILE echo "### Произошла ошибка! Бэкап не удался. ###" >>$LOGFILE echo "###########################################" >>$LOGFILE echo "$(date +"%d-%b-%Y %R%nФайл") бекапа $OF не создан" | sendxmpp -t -f /usr/local/etc/XMPP_settings логин_получателя@домен &>>$LOGFILE else echo "Файл бэкапа сохранен как \"$TGTD$OF\"" >>$LOGFILE echo "Бэкап успешно завершен в $(date +"%R %d-%b-%Y")!" >>$LOGFILE echo "Монтирование файловой системы для резервного архива $TGTD_archive" >>$LOGFILE mount $TGTD2 &>>$LOGFILE if [[ $? != 0 ]]; then echo "#############################################################" >>$LOGFILE echo "### Произошла ошибка при монтировании резервного ресурса ###" >>$LOGFILE echo "#############################################################" >>$LOGFILE echo "$(date +"%d-%b-%Y %R%nФайл") бекапа $OF не скопирован на резервный ресурс" | sendxmpp -t -f /usr/local/etc/XMPP_settings логин_получателя@домен &>>$LOGFILE exit fi echo "Начато копирование файла на резервный ресурс" >>$LOGFILE cp -f $TGTD$OF $TGTD_archive$OF &>>$LOGFILE if [[ $? != 0 ]]; then echo "#############################################################" >>$LOGFILE echo "### Произошла ошибка при копировании на резервный ресурс ###" >>$LOGFILE echo "#############################################################" >>$LOGFILE echo "$(date +"%d-%b-%Y %R%nФайл") бекапа $OF не скопирован на резервный ресурс" | sendxmpp -t -f /usr/local/etc/XMPP_settings логин_получателя@домен &>>$LOGFILE else echo "Копирование файла успешно завершено в $(date +"%R %d-%b-%Y")!" >>$LOGFILE echo "Файл скопирован как \"$TGTD_archive$OF\"" >>$LOGFILE fi echo "Размонтирование файловой системы для резервного архива $TGTD_archive" >>$LOGFILE umount $TGTD2 &>>$LOGFILE echo "Все операции завершены успешно!" >>$LOGFILE fi exit

В процессе мы копируем архив из локального хванилища в удаленное. Естественно, проверяем, что каждая операция успешно завершена, и пишем все в логи.
Для отсылки сообщения администратору я использую XMPP сообщение, так как в организации поднят Jabber-сервер, и я больше люблю получить быстрое сообщение о сбое, чем лезть в почту, вбивая пароли, тыкая на ссылки, и ожидая пока браузер мне все отобразит. В любом случае никто не мешает вам использовать sendmail вместо sendxmpp.
Файл /usr/local/etc/XMPP_settings следующего содержания:

#логин_отправителя@домен;IP_jabber_сервера:порт_jabber_сервера пароль_отправителя login@domen;127.0.0.1:5222 password
В файле fstab строка описывающая подключение шары Windows
//192.168.0.250/arhiv /mnt/archive cifs noauto,rw,iocharset=utf8,cp866,file_mod=0666,dir_mod=0777,noexec,_netdev,credentials=/root/.passwd_to_archive_directory 0 0
Теперь осталось только добавить задание в cron. Это можно сделать с помощью файла /etc/crontab, но я, в силу привычки к GUI, оставшейся в наследство от виндовс, пользую вэб-интерфейсы для таких случаев. Команда должна выполняться с правами рута, то бишь, к примеру, sudo bash backup_script. Добавляя команду в cron можно определить что она будет сразу выполняться от имени root`а

В ходе обсуждений затронули проблему разрастания логов. Пошел по простейшему (на мой взгляд) пути: будем хранить только последние N строк лога, например 300. В скрипт добавятся две строки, в которых мы сохраним последние 300 строк лога во временный файл, потом затрем им лог
tail -n 300 $LOGFILE >/tmp/unique_fantastic_filename.tmp mv -f /tmp/unique_fantastic_filename.tmp $LOGFILE
Приведу полный текст скрипта:
#!/bin/bash TN=docs-monthly #TN=docs-weekly #TN=docs-daily OF=$TN.tar.gz LOGFILE=/var/log/backup.log echo >>$LOGFILE echo "=====================================================" >>$LOGFILE echo "$(date +"%d-%b-%Y %R")" >>$LOGFILE echo "Задание \"$TN\" запущено..." >>$LOGFILE OLD_IFS=$IFS IFS=$"\n" SRCD="/mnt/source/folder_1 /mnt/source/folder_2 /mnt/source/folder_N" TGTD="/var/backups/" TGTD2="/mnt/archive/" tar -czf $TGTD$OF $SRCD &>>$LOGFILE #tar -u -f $TGTD$OF $SRCD &>>$LOGFILE STATUS=$? IFS=$OLD_IFS if [[ $STATUS != 0 ]]; then rm $TGTD$OF &>>$LOGFILE echo "###########################################" >>$LOGFILE echo "### Произошла ошибка! Бэкап не удался. ###" >>$LOGFILE echo "###########################################" >>$LOGFILE echo "$(date +"%d-%b-%Y %R%nФайл") бекапа $OF не создан" | sendxmpp -t -f /usr/local/etc/XMPP_settings логин_получателя@домен &>>$LOGFILE else echo "Файл бэкапа сохранен как \"$TGTD$OF\"" >>$LOGFILE echo "Бэкап успешно завершен в $(date +"%R %d-%b-%Y")!" >>$LOGFILE echo "Монтирование файловой системы для резервного архива $TGTD_archive" >>$LOGFILE mount $TGTD2 &>>$LOGFILE if [[ $? != 0 ]]; then echo "#############################################################" >>$LOGFILE echo "### Произошла ошибка при монтировании резервного ресурса ###" >>$LOGFILE echo "#############################################################" >>$LOGFILE echo "$(date +"%d-%b-%Y %R%nФайл") бекапа $OF не скопирован на резервный ресурс" | sendxmpp -t -f /usr/local/etc/XMPP_settings логин_получателя@домен &>>$LOGFILE exit fi echo "Начато копирование файла на резервный ресурс" >>$LOGFILE cp -f $TGTD$OF $TGTD_archive$OF &>>$LOGFILE if [[ $? != 0 ]]; then echo "#############################################################" >>$LOGFILE echo "### Произошла ошибка при копировании на резервный ресурс ###" >>$LOGFILE echo "#############################################################" >>$LOGFILE echo "$(date +"%d-%b-%Y %R%nФайл") бекапа $OF не скопирован на резервный ресурс" | sendxmpp -t -f /usr/local/etc/XMPP_settings логин_получателя@домен &>>$LOGFILE else echo "Копирование файла успешно завершено в $(date +"%R %d-%b-%Y")!" >>$LOGFILE echo "Файл скопирован как \"$TGTD_archive$OF\"" >>$LOGFILE fi echo "Размонтирование файловой системы для резервного архива $TGTD_archive" >>$LOGFILE umount $TGTD2 &>>$LOGFILE echo "Все операции завершены успешно!" >>$LOGFILE fi tail -n 300 $LOGFILE >/tmp/unique_fantastic_filename.tmp mv -f /tmp/unique_fantastic_filename.tmp $LOGFILE exit

Всем спасибо за внимание!