1. Проста схема резервного копіювання
2. Лістинг 1. Shell-скрипт arc
3. Лістинг 2. Архівування каталогу beoserver
4. Складні схеми резервного копіювання
5. Малюнок 1. Розподілена мережа
6. Захищений віддалений доступ з використанням відкритих / закритих ключів
7. Лістинг 3. Намагайтеся вибрати гарну парольний фразу
8. Лістинг 4. Установка відкритих ключів на віддалені сервери
9. Лістинг 5. Додавання offsite.pub до списку авторизованих ключів
10. Лістинг 6. Зміна прав доступу командою chmod
11. Автоматизація доступу до комп'ютера за допомогою ssh-агента
12. Лістинг 7. ssh-agent в дії
13. Лістинг 8. Використання ssh-add для входу на сервер без зайвих труднощів
14. Спрощений доступ до ключів за допомогою скрипта keychain
15. Лістінг 9. Ініціалізація keychain на кожному сервері
16. Автоматизація процесса резервного Копіювання
17. Лістинг 10. Скрипт dbbackup.sh для сервера 1
18. Лістинг 11. Скрипт backup_remote_servers.sh для розміщення на сервері зовнішнього сховища
19. планування завдань
20. Лістинг 12. Записи crontab на сервері зовнішнього сховища
21. Лістинг 13. Формат запису crontab
22. Верифікація резервних копій
23. Додаткові заходи забезпечення інформаційної безпеки
24. Висновок
25. Ресурси для скачування

Ніяких відмовок: безпечне розподілене мережеве резервне копіювання своїми руками

Якщо ви - користувач Linux, то у вашому розпорядженні вже є виключно потужні інструменти для створення спеціалізованих рішень резервного копіювання. Рішення, описані в даній статті, дозволяють виконувати як просте, так і більш просунуте мережеве резервне копіювання, використовуючи інструменти з відкритими початковими кодами, що входять до складу практично будь-якого дистрибутива Linux.

Проста схема резервного копіювання

Щоб спростити освоєння матеріалу, в даній статті використовується покроковий підхід.

Ми почнемо з простого, але ефективного механізму архівування, а потім перейдемо до розширеного рішенням для розподіленого резервного копіювання. Погляньте на зручний скрипт arc, що дозволяє створювати резервні копії з командного рядка Linux.

Лістинг 1. Shell-скрипт arc

#! / Bin / sh tar czvf $ 1. $ (Date +% Y% m% d-% H% M% S) .tgz $ 1 exit $?

Скрипт arc приймає як параметр шлях до файлу або каталогу, після чого створює архівний файл, ім'я якого містить поточну дату. Наприклад, для архівації каталогу beoserver скрипту arc необхідно передати шлях до нього, після чого буде сформовано стислий архів, який має ім'я приблизно наступного вигляду: beoserver.20040321-014844.tgz

Впорядкувати архівні файли допоможе включення в їх імена дати і часу за допомогою команди date. Дата має наступний формат: рік, місяць, день, годину, хвилини, секунди - секунди, ймовірно, в нашому випадку вже зайві. Про параметрах команди date можна дізнатися з її керівництва, переглянути яку можна командою man date. Крім того, в лістингу 1 ми використовуємо параметр -v (verbose, докладно) команди tar. Команда tar, запущена з даними параметром, відображає імена всіх архівних файлів. Якщо цього не потрібно, параметр -v можна прибрати.

Лістинг 2. Архівування каталогу beoserver

$ Ls arc beoserver $ ./arc beoserver beoserver / beoserver / bookl.dat beoserver / beoserver_ab_off beoserver / beoserver_ab_on $ ls arc beoserver beoserver.20040321-014844.tgz

Складні схеми резервного копіювання

Проста схема резервного копіювання вельми корисна, але вона вимагає ручного виконання операцій. Кращі галузеві методики рекомендують регулярно створювати резервні копії, зберігати резервні копії на різних носіях і в різних місцях. Базовий принцип полягає в тому, щоб уникати залежності від єдиного носія або місця зберігання носіїв.

Ми будемо вирішувати цю проблему в наступному прикладі, заснованому на деякій розподіленої мережі, схема якої, наведена на малюнку 1, включає системного адміністратора, що має доступ до двох віддалених серверів і зовнішньому сховища даних.

Малюнок 1. Розподілена мережа

Резервні копії файлів, що знаходяться на Сервері №1 і Сервері №2, будуть безпечним чином передаватися у зовнішнє сховище; весь процес розподіленого резервного копіювання буде виконуватися повністю автоматично на регулярній основі. Ми скористаємося стандартним набором інструментів, до якого входять програми з пакету Open Secure Shell (OpenSSH), стрічковий архіватор (tar) та служба планування завдань cron. У загальному вигляді наш план полягає у використанні cron для планування завдань резервного копіювання, реалізованих за допомогою shell-скриптів і стрічкового архиватора tar. Захищена оболонка (ssh) буде забезпечувати шифрування трафіку і аутентифікацію користувачів, а програма захищеного копіювання (scp) - автоматизацію передачі файлів. Попередньо рекомендую ознайомитися з інструкціями щодо використання всіх перерахованих інструментів.

Захищений віддалений доступ з використанням відкритих / закритих ключів

В контексті інформаційної безпеки ключ являє собою дані, які використовуються для шифрування і розшифрування інших даних. Принцип роботи відкритого і закритого ключів цікавий тим, що дані, зашифровані відкритим ключем, можуть бути розшифровані тільки за допомогою відповідного закритого ключа. Відкритий ключ можна вільно поширювати щоб інші люди могли шифрувати їм повідомлення, адресовані вам. Однією з причин, по яким схеми з відкритим ключем зробили революцію в інформаційній безпеці, є відсутність у відправника і одержувача повідомлення необхідності в загальному ключі або паролі. Крім інших корисних речей, криптографія з відкритим ключем уможливила електронну торгівлю та інші види захищених транзакцій. У цій статті ми створимо відкритий і секретний ключі, які будемо використовувати для створення захищеного рішення для розподіленого резервного копіювання.

На кожному комп'ютері, задіяному в процесі резервного копіювання, повинна бути запущена служба захищеної оболонки OpenSSH (sshd). Використовуваний службою порт 22 повинен бути відкритий для даних машин на всіх проміжних мережевих екранах. Якщо ви працюєте з віддаленими серверами, велика ймовірність, що ви робите це за допомогою захищеної оболонки.

Ми постараємося забезпечити віддалений доступ до комп'ютерів, уникнувши необхідності вказувати паролі вручну. Існує думка, що найлегшим способом вирішення даного завдання є відмова від використання паролів: так робити не потрібно. Це не безпечно. Підхід, який ми розглянемо в даній статті, дозволить за годину налаштувати систему, що забезпечує високий рівень інформаційної безпеки, і при цьому зберігає всі переваги "беспарольного" доступу.

Для початку перевіримо, чи встановлений пакет OpenSSH, і з'ясуємо номер його версії. На момент написання цієї статті останнім випуском OpenSSH була версія 3.8, що побачила світ 24 лютого 2004 г. Рекомендується використовувати найбільш свіжий і стабільний випуск, принаймні більш пізній, ніж версія 2.x. Для отримання докладної інформації про уразливість, виявлених в ранніх версіях OpenSSH, відвідайте сторінку OpenSSH Security (посилання наведена нижче в розділі ресурси ). На даний момент OpenSSH є цілком стабільною програмою, яка не має вразливостей, виявлених в інших SSH-інструментах.

Для відображення версії програми виконайте команду ssh з параметром V (прописна буква):

$ Ssh -V
OpenSSH_3.5p1, SSH protocols 1.5 / 2.0, OpenSSL 0x0090701f

Якщо команда ssh відобразила версію вище 2.x, даний комп'ютер знаходиться у відносно непоганій формі. Рекомендується проте використовувати останні стабільні випуски всього встановленого програмного забезпечення - особливо це важливо для засобів інформаційної безпеки.

Нашим першим кроком буде вхід на сервер зовнішнього сховища під обліковим записом, яка матиме доступ до серверів 1 і 2 (рисунок 1).

$ Ssh [email protected]

Після входу на сервер зовнішнього сховища створіть пару з відкритого і секретного ключів, запустивши програму ssh-keygen з параметром -t dsa. Параметр -t є обов'язковим і використовується для вказівки типу ключа шифрування, який потрібно згенерувати. Ми скористаємося алгоритмом Digital Signature Algorithm (DSA), що дозволяє застосовувати новий протокол SSH2. Додаткову інформацію з даного питання можна отримати, ознайомившись з керівництвом до програми ssh-keygen.

Після запуску ssh-keygen вам буде запропоновано вказати каталог, в якому будуть створені файли ssh-ключів, після чого буде запропоновано ввести відповідний пароль. Якщо на питання про каталог для збереження ключів відповісти простим натисканням Enter, програма створить прихований каталог .ssh (якщо він не був створений раніше), в якому будуть знаходитися два файли, що містять відкритий і секретний ключі.

Цікавою можливістю ssh-keygen є те, що програма дозволяє користувачеві відмовитися від введення парольної фрази, натиснувши Enter у відповідь на відповідний запит. Якщо парольний фраза не вказана, ssh-keygen згенерує незашифровані ключі. Неважко здогадатися, що це - не найкраща ідея. У відповідь на запит парольної фрази слід ввести текстове повідомлення розумної довжини, що складається з алфавітно-цифрових символів, а не обмежуватися звичайним односкладових паролем.

Лістинг 3. Намагайтеся вибрати гарну парольний фразу

[Offsite]: $ ssh-keygen -t dsa Generating public / private dsa key pair. Enter file in which to save the key (/home/accountname/.ssh/id_dsa): Enter passphrase (empty for no passphrase): (enter passphrase) Enter same passphrase again: (enter passphrase) Your identification has been saved in / home /accountname/.ssh/id_dsa. Your public key has been saved in /home/accountname/.ssh/id_dsa.pub. The key fingerprint is: 7e: 5e: b2: f2: d4: 54: 58: 6a: fa: 6b: 52: 9c: da: a8: 53: 1b accountname @ offsite

Оскільки каталог .ssh, створюваний ssh-keygen, є прихованим, щоб його побачити, необхідно виконати команду ls з параметром -a.

[Offsite] $ ls -a
. .. .bash_logout .bash_profile .bashrc .emacs .gtkrc .ssh

Перейдіть в прихований каталог .ssh і виведіть його вміст:

[Offsite] $ cd .ssh
[Offsite] $ ls -lrt
id_dsa id_dsa.pub

Видно, що в прихованому каталозі .ssh знаходяться файли секретного (id_dsa) і відкритого (id_dsa.pub) ключів. Переглянути вміст цих файлів можна за допомогою текстового редактора, наприклад, vi або emacs, або скориставшись командами less або cat. При перегляді вмісту файлів ви побачите, що воно складається з алфавітно-цифрових символів кодування base64.

Далі нам потрібно скопіювати і встановити відкритий ключ на сервери 1 і 2. Не потрібно використовувати для цього ftp. Замість цього скористайтеся програмою захищеного копіювання.

Лістинг 4. Установка відкритих ключів на віддалені сервери

[Offsite] $ scp .ssh / id_dsa.pub [email protected]: offsite.pub [email protected]'s password: (enter password, not new passphrase!) Id_dsa.pub 100% | ******** ********************* | 614 00:00 [offsite] $ scp .ssh / id_dsa.pub [email protected]: offsite.pub [email protected]'s password: (enter password, not new passphrase!) Id_dsa.pub 100% | **** ************************* | 614 00:00

Після установки нових відкритих ключів ми зможемо заходити на кожен з серверів, використовуючи парольний фразу, вказану при створенні відкритого і секретного ключів. А поки увійдіть кожен з серверів і додайте вміст файлу offsite.pub в кінець файлу authorized_keys, що знаходиться в каталозі .ssh. Це можна зробити за допомогою текстового редактора або команди cat:

Лістинг 5. Додавання offsite.pub до списку авторизованих ключів

[Offsite] $ ssh [email protected] [email protected]'s password: (enter password, not new passphrase!) [Server1] $ cat offsite.pub >> ./ssh/authorized_keys

На наступному кроці ми приймемо додаткові заходи безпеки. Спочатку ми змінимо права доступу до .ssh таким чином, щоб доступ до даного каталогу на читання, запис і виконання мав тільки його власник. Потім ми переконаємося, що доступ до файлу authorized_keys має тільки його власник. І нарешті, ми видалимо за непотрібністю раніше завантажений файл відкритого ключа offsite.pub. Дуже важливо правильно призначити права доступу, оскільки сервер OpenSSH може відмовити у використанні ключів, для файлів яких задані небезпечні права доступу.

Лістинг 6. Зміна прав доступу командою chmod

[Server1] $ chmod 700 .ssh [server1] $ chmod 600 ./ssh/authorized_keys [server1] $ rm offsite.pub [server1] $ exit

Після виконання цього процесу на сервері 2 ми перейдемо на сервер зовнішнього сховища для перевірки роботи нового способу доступу, заснованого на пральний фразі. Зробити це можна, виконавши наступну команду на сервері зовнішнього сховища:

[Offsite] $ ssh -v [email protected]

Параметр -v, що включає режим виведення докладних повідомлень, дозволяє відображати зневадження в ході перевірки доступу вашого профілю до віддаленого сервера з використанням нової парольної фрази замість початкового пароля. У зневадження входять відомості, недоступні користувачеві в інших умовах, в тому числі Високорівнева інформація про роботу процесу аутентифікації. В ході звичайної роботи вказувати параметр -v немає необхідності, але при перевірці з'єднання це дуже корисно.

Автоматизація доступу до комп'ютера за допомогою ssh-агента

ssh-агент грає роль шлюзу, на вимогу надає безпечний доступ до ключів. Після запуску ssh-агент працює в фоновому режимі і може використовуватися такими програмами пакету OpenSSH як, наприклад, ssh або scp. З його допомогою програма ssh може використовувати заздалегідь розшифрований ключ замість того, щоб запитувати парольний фразу при кожній необхідності.

Давайте поглянемо на програму ssh-agent ближче. Ssh-agent виводить команди:

Лістинг 7. ssh-agent в дії

[Offsite] $ ssh-agent SSH_AUTH_SOCK = / tmp / ssh-XX1O24LS / agent.14179; export SSH_AUTH_SOCK; SSH_AGENT_PID = 14180; export SSH_AGENT_PID; echo Agent pid 14180;

Ми можемо вказати оболонці виконувати команди, виведені програмою ssh-agent, за допомогою вбудованої команди eval:

[Offsite] $ eval `ssh-agent`
Agent pid 14198

Команда eval обчислює (виконує) команди, які генеруються програмою ssh-agent. Переконайтеся, що використовуються саме зворотні ( `), а не одинарні лапки! Команда eval `ssh-agent` повертає ідентифікатор процесу агента. Непомітно для нас були експортовані змінні оболонки SSH_AUTH_SOCK і SSH_AGENT_PID. Їх значення можна переглянути шляхом виведення в консоль за допомогою такої команди:

[Offsite] $ echo $ SSH_AUTH_SOCK
/tmp/ssh-XX7bhIwq/agent.14197

Змінна $ SSH_AUTH_SOCK (скорочення від SSH Authentication Socket) містить шлях до локального сокета, призначеному для зв'язку додатків з програмою ssh-agent. Щоб переконатися в тому, що змінні SSH_AUTH_SOCK і SSH_AGENT_PID завжди задані, додайте команду eval `ssh-agent` в файл ~ / .bash_profile.

Після цього ssh-agent стає фоновим процесом, побачити який можна за допомогою команд top і ps.

Тепер ми можемо організувати з його допомогою спільний доступ до пральний фразі. Для того, щоб це зробити, нам потрібна програма ssh-add, що додає (відправляє) парольний фразу програмі ssh-agent.

Лістинг 8. Використання ssh-add для входу на сервер без зайвих труднощів

[Offsite] $ ssh-add Enter passphrase for /home/accountname/.ssh/id_dsa: (enter passphrase) Identity added: /home/accountname/.ssh/id_dsa (/home/accountname/.ssh/id_dsa)

Тепер при отриманні доступу до server1 парольний фраза запитуватися не буде:

[Offsite] $ ssh [email protected]
[Server1] $ exit

Якщо наведений приклад здається вам непереконливим, спробуйте вивантажити (kill -9) процес ssh-agent і повторно підключитися до server1. В цьому випадку ви помітите, що server1 запросить парольний фразу секретного ключа, що зберігається в файлі id_dsa, який знаходиться в каталозі .ssh.

[Offsite] $ kill -9 $ SSH_AGENT_PID
[Offsite] $ ssh [email protected]
Enter passphrase for key '/home/accountname/.ssh/id_dsa':

Спрощений доступ до ключів за допомогою скрипта keychain

До даного моменту ми дізналися, як працюють деякі програми пакета OpenSSH (ssh, scp, ssh-agent і ssh-add), а також створили і встановили секретний і відкритий ключі для того, щоб забезпечити безпечний автоматичний процес входу на сервер. Ви, ймовірно, вже зрозуміли, що більшу частину роботи з налаштування потрібно виконати тільки один раз. Наприклад, процес створення і установки ключів, а також настройка запуску ssh-agent з .bash_profile виконуються тільки один раз для кожного сервера. Це добре.

Погано те, що програма ssh-add повинна запускатися кожен раз, коли ми входимо на сервер зовнішнього сховища і, крім цього, в тому, що забезпечення сумісності програми ssh-agent з планувальником с, який буде потрібно нам для організації резервного копіювання, вимагає додаткових зусиль . Причина нездатності cron взаємодіяти з ssh-agent полягає в тому, що завдання cron виконуються як дочірні процеси планувальника і тому не отримують копію змінної $ SSH_AUTH_SOCK.

На щастя, дана проблема має рішення, що дозволяє не тільки зняти обмеження, пов'язані з використанням ssh-agent і ssh-add, а й використовувати cron для автоматизації всіх видів завдань, що вимагають безпечного беспарольного доступу до віддалених машин. У своєму циклі OpenSSH key management (посилання наведена в розділі ресурси ), Що складається з трьох статей, опублікованих developerWorks в 2001 році, Деніел Роббінс (Daniel Robbins) представив скрипт keychain, що представляє собою інтерфейс до програм ssh-agent і ssh-add, який полегшує процес беспарольного доступу. Згодом був зроблений ряд поліпшень даного скрипта, який тепер підтримується Ароном Гріффіс (Aron Griffis). Останній випуск, датований 17 червня 2004 року, має номер 2.3.2-1.

Текст скрипта keychain занадто великий для того, щоб його можна було привести в даній статті, оскільки він, як і будь-який якісно написаний скрипт, включає велику кількість перевірок виникнення помилок, детальну документацію і значний обсяг кроссплатформенного коду. Незважаючи на великі можливості, скрипт keychain можна швидко завантажити з web-сайту проекту (посилання наведена в розділі Схожі теми ).

Працювати зі скриптом, після того як ви його завантажити та встановити, дуже просто. Просто зайдіть на кожен з серверів і додайте наступні два рядки в кінець файлів .bash_profile:

keychain id_dsa
. ~ / .Keychain / $ HOSTNAME-sh

Коли ви зайдете на сервери в наступний раз, keychain запросить парольний фразу. При наступних входах, однак, введення пральний фрази не буде запитуватися до моменту перезавантаження сервера. І, що найголовніше, завдання cron зможуть здійснювати безпечний доступ до віддалених машин без введення пароля. Тепер наше рішення поєднує переваги підвищеної безпеки і простоти використання.

Лістінг 9. Ініціалізація keychain на кожному сервері

KeyChain 2.3.2; http://www.gentoo.org/projects/keychain Copyright 2002-2004 Gentoo Technologies, Inc.; Distributed under the GPL * Initializing /home/accountname/.keychain/localhost.localdomain-sh file ... * Initializing /home/accountname/.keychain/localhost.localdomain-csh file ... * Starting ssh-agent * Adding 1 key (s) ... Enter passphrase for /home/accountname/.ssh/id_dsa: (enter passphrase)

Автоматизація процесса резервного Копіювання

Нашої Наступний завдання є написання скриптів, что віконують операции, необхідні для резервного Копіювання. Метою роботи Даних скриптів буде создания повної резервної копії баз Даних, что знаходяться на серверах server1 и server2. На кожному з серверів в розглянутому прикладі встановлена ​​СУБД MySQL. Відповідно для експорту кількох таблиць у вигляді SQL-скрипта ми будемо використовувати утиліту mysqldump, що працює в командному рядку.

Лістинг 10. Скрипт dbbackup.sh для сервера 1

#! / Bin / sh # переходимо в каталог backup_agent, в якому зберігаються файли даних. cd / home / backup_agent # експортуємо таблиці баз даних за допомогою утиліти mysqldump mysqldump -u sitedb -pG0oDP @ sswrd --add-drop-table sitedb - tables tbl_ccode tbl_machine tbl_session tbl_stats> userdb.sql # архівуємо і стискаємо файли tar czf userdb. tgz userdb.sql

На сервері 2 ми розмістимо аналогічний скрипт, який здійснює резервне копіювання унікальних таблиць встановленої на ньому БД. Для кожного з скриптів необхідно задати ознака виконуваного файлу, виконавши команду:

[Server1]: $ chmod + x dbbackup.sh

Розмістивши копії файлу dbbackup.sh на серверах 1 і 2, ми повертаємося на сервер зовнішнього сховища, де створюємо скрипт, що виконує їх перед запуском процесу віддаленого копіювання стиснутих архівів (.tgz).

Лістинг 11. Скрипт backup_remote_servers.sh для розміщення на сервері зовнішнього сховища

#! / Bin / sh # використовуємо ssh для віддаленого виконання скрипта dbbackup.sh на сервері 1 / usr / bin / ssh [email protected] "/home/backup_agent/dbbackup.sh" # використовуємо scp для безпечного копіювання створеного архівного файлу userdb .tgz # з сервера 1. Зверніть увагу на використання команди date для формування тимчасової позначки # при розміщенні файлу на сервері зовнішнього сховища. / Usr / bin / scp [email protected]: /home/backup_agent/userdb.tgz / home / backups / userdb - $ (date +% Y% m% d-% H% M% S) .tgz # виконуємо скрипт dbbackup.sh на сервері 2 / usr / bin / ssh [email protected] "/home/backup_agent/dbbackup.sh" # використовуємо scp для копіювання transdb.tgz на сервер зовнішнього сховища. / Usr / bin / scp [email protected]: /home/backup_agent/transdb.tgz / home / backups / transdb - $ (date +% Y% m% d-% H% M% S) .tgz

Скрипт backup_remote_servers.sh використовує ssh для віддаленого виконання скриптів на серверах. Оскільки доступ, організований нами, не вимагає введення пароля, програма ssh може віддалено виконувати команди на серверах 1 і 2 з сервера зовнішнього сховища. Завдяки keychain процес аутентифікації відбувається повністю автоматично.

планування завдань

Наша наступна і остання задача полягає в плануванні виконання скрипта backup_remote_servers.sh на сервері зовнішнього сховища. Для цього ми додамо в конфігураційний файл планувальника cron дві нові записи, згідно з якими скрипт резервного копіювання буде запускатися двічі в день - в 3:34 і о 20:34. Щоб додати записи, запустіть на сервері зовнішнього сховища програму crontab з параметром -e.

[Offsite]: $ crontab -e

Програма crontab запустить яка буде використовуватися під текстовий редактор, вказаний в змінних середовища VISUAL або EDITOR. Тепер введіть дві нові записи, після чого збережіть і закрийте файл.

Лістинг 12. Записи crontab на сервері зовнішнього сховища

34 3 * * * /home/backups/remote_db_backup.sh 34 20 * * * /home/backups/remote_db_backup.sh

Запис файлу crontab складається з двох основних частин: специфікації часу виконання і команди, яка підлягає виконанню. Специфікація часу виконання включає наступні поля:

Лістинг 13. Формат запису crontab

+ ---- хвилина | + ----- годину | | + ------ день | | | + ------ місяць | | | | + ---- день тижня | | | | | + - команда, яка підлягає виконанню | | | | | | 34 3 * * * /home/backups/remote_db_backup.sh

Верифікація резервних копій

Рекомендується регулярно проводити перевірку резервних копій щоб переконатися в правильній роботі процесу. Автоматизація процесів допомагає позбутися від непотрібної рутини, але замінити сумлінного ставлення до справи вона не може. Якщо ваші дані заслуговують резервного копіювання, то час від часу має сенс проводити вибіркову перевірку якості його виконання.

Можливо, варто створити завдання планувальника cron, яка щонайменше раз на місяць нагадувала б вам про необхідність перевірки резервних копій. Крім того, непогано було б міняти ключову пару після закінчення певного періоду; нагадати вам про це може також завдання планувальника cron.

Додаткові заходи забезпечення інформаційної безпеки

Для підвищення рівня інформаційної безпеки можна встановити і налаштувати на кожному сервері систему виявлення вторгнень (Intrusion Detection System, IDS), наприклад, Snort. Система виявлення вторгнень призначена для оповіщення про спроби злому системи, що відбуваються в даний момент або мали місце нещодавно. Наявність такої системи дозволить нарощувати рівень інформаційної безпеки за рахунок застосування таких технологій як цифровий підпис і шифрування резервних копій.

Архівні файли можна захистити за допомогою поширених інструментів з відкритим вихідним кодом, наприклад GNU Privacy Guard (GnuPG), OpenSSL і ncrypt, однак, застосовувати їх без додаткового рівня захисту, що надається системою виявлення вторгнень, не рекомендується (посилання на додаткову інформацію по Snort наведені в розділі ресурси ).

Висновок

У статті було продемонстровано віддалене виконання скриптів на серверах і здійснення безпечного автоматичного копіювання файлів. Я сподіваюся, що її прочитання дало вам інформацію для роздумів про те, як захистити ваші цінні дані за допомогою таких інструментів з відкритими початковими кодами, як OpenSSH і Snort.

Ресурси для скачування

Схожі тими

• оригінал статті Automate backups on Linux (EN) (developerWorks, липень 2004 року, оновлено: липень 2008 р).
• На Офіційному сайті OpenSSH і сторінці OpenSSH Security ви знайдете файли для завантаження, документацію і багато іншої інформації.
• Прочитайте чудовий цикл з трьох статей, написаний Деніелом Роббінс для IBM developerWorks " OpenSSH Key Management "(EN) (developerWorks, 2001) і завантажте написане ним додаток keychain .
• Тим, хто хоче дізнатися більше про SSH, Карлос рекомендує книгу видавництва O'Reilly SSH, The Secure Shell: The Definitive Guide (EN) (O'Reilly & Associates, 2001 г.).
• Система виявлення вторгнень Snort - кращий інструмент даного типу з відкритими початковими кодами, призначений для виявлення та інформування про випадки несанкціонованого доступу або підозрілої поведінки. Рекомендуємо використовувати систему виявлення вторгнень при організації автоматичної підпису та шифрування архівних файлів,
• Архівні файли резервних копій можна підписувати і шифрувати за допомогою скриптів, які використовують GNU Privacy Guard (GnuPG), OpenSSL и ncrypt .
• Любителів Perl повинні зацікавити статті Теда Златанова (Ted Zlatanov) " Automating UNIX system administration with Perl "(EN) (developerWorks, 2001 г.)," Intro to cfengine for system administration "(EN) (developerWorks, 2002 г.), and" Application configuration with Perl "(EN) (developerWorks, 2000 г.).
• Стаття " Windows-to-Linux roadmap: Part 8. Backup and recovery "(EN) (developerWorks, 2003), опублікована на сайті developerWorks, містить поради щодо вибору стратегії резервного копіювання.
• IBM Tivoli Storage Manager для Linux (EN) дозволяє автоматизувати і забезпечити проведення за розкладом надійного резервного копіювання, архівування та централізованого управління даними на робочих станціях і серверах, що працюють під управлінням Linux. Кроме того, лінійка продуктів Tivoli включає інструменти для управління користувачами, управління доступом, моніторингу мережі і багато чого іншого, пропонуючи при цьому уніфіковану середу і інтерфейс.
• Дізнайтеся більше про рішення Tivoli в розділі сайту IBM developerWorks, присвяченому Tivoli .
• В розділі сайту developerWorks, присвяченому Linux , Можна знайти інші матеріали для Linux-розробників.
• Розробляйте і тестируйте ваші програми для Linux за допомогою новітніх інструментів і ПО проміжного шару, пропонованих IBM по підписці developerWorks (EN): ви отримуєте таке програмне забезпечення IBM як WebSphere, DB2, Lotus, Rational і Tivoli разом з ліцензією, що дає право користування ним протягом 12 місяців - все це за менші гроші, ніж ви припускаєте.

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів