Власний сервер дозволяє самостійно керувати сайтами, базами даних, поштовими скриньками, доменами та доступом користувачів. У цьому історичному матеріалі розглядається створення такої системи на базі Ubuntu Server 12.04 LTS із панеллю керування ISPConfig 3.

ISPConfig 3 об’єднувала керування основними службами хостингу в одному веб-інтерфейсі. Через панель можна було додавати сайти, створювати FTP-користувачів, керувати базами MySQL, поштовими доменами, DNS-зонами, квотами та обліковими записами клієнтів.

Сьогодні Ubuntu 12.04 та наведені в оригінальній інструкції версії програмного забезпечення вважаються застарілими. Тому матеріал слід використовувати для ознайомлення з будовою класичного Linux-сервера, а не як готову інструкцію для сучасної робочої системи.

Підготовка до встановлення

Для розгортання сервера була потрібна інсталяційна система Ubuntu Server, стабільне підключення до інтернету та окремий комп’ютер або віртуальна машина.

Перед початком визначалися основні параметри майбутнього сервера:

ім’я хоста;

повне доменне ім’я;

постійна IP-адреса;

мережева маска;

шлюз;

DNS-сервери;

структура дисків;

ім’я адміністративного користувача.

У прикладі сервер отримував повне ім’я server1.example.com і статичну адресу в локальній мережі. У реальній конфігурації ці значення необхідно було замінити власними.

Встановлення Ubuntu Server

Після завантаження з інсталяційного носія користувач обирав мову, регіон, розкладку клавіатури та часовий пояс.

Далі встановлювач пропонував вибрати диск. Для простої системи використовувалася автоматична розмітка всього накопичувача. Вона створювала основний логічний том для системи та окремий простір підкачки.

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

Після форматування диска встановлювалася базова система. Потім створювався звичайний користувач із паролем. Використовувати для нього ім’я Admin не рекомендувалося, оскільки воно могло бути зарезервованим.

Шифрування домашнього каталогу було необов’язковим. Для серверної системи його часто не використовували, щоб уникнути додаткових складнощів під час автоматичної роботи служб.

На етапі вибору програмного забезпечення встановлювався OpenSSH Server. Інші компоненти хостингу не обиралися, оскільки їх планували додати вручну та повністю контролювати конфігурацію.

Після завершення встановлення додавався завантажувач GRUB, інсталяційний носій видалявся, а сервер перезавантажувався.

Адміністративний доступ

Після першого входу подальші дії виконувалися з підвищеними правами. Для тимчасового переходу в режим адміністратора використовувалася команда:

sudo su

Також існувала можливість задати окремий пароль для root. Проте постійний прямий вхід під root створює додаткові ризики безпеки. Для сучасних серверів краще використовувати звичайного користувача, sudo та авторизацію за SSH-ключами.

Якщо OpenSSH не був встановлений разом із системою, його можна було додати окремо. Після цього сервером керували віддалено через SSH-клієнт.

Статична мережева конфігурація

Сервер не повинен залежати від випадкової адреси, виданої DHCP. Тому мережевий інтерфейс переводився на статичну конфігурацію.

У налаштуваннях зазначалися:

IP-адреса сервера;

маска підмережі;

мережева адреса;

широкомовна адреса;

основний шлюз;

DNS-сервери.

Після збереження конфігурації мережеву службу перезапускали. Окремо редагувався файл hosts, у якому локальна адреса пов’язувалася з повним доменним і коротким іменами сервера.

Правильність налаштування перевірялася командами hostname і hostname -f. Сервер мав повертати коректне повне доменне ім’я.

Оновлення системи

Після налаштування мережі редагувався список джерел пакетів. Посилання на інсталяційний диск вимикалися, а основні репозиторії, оновлення та пакети безпеки залишалися активними.

Потім оновлювався список пакетів і встановлювалися доступні виправлення. Якщо оновлювалося ядро, систему перезавантажували.

Оригінальна інструкція також рекомендувала змінити стандартну оболонку /bin/sh із Dash на Bash через вимоги старого інсталятора ISPConfig.

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

Синхронізація часу

Для правильного формування журналів, роботи пошти, SSL-сертифікатів і завдань cron встановлювалися служби синхронізації часу.

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

База даних і поштові служби

Наступним етапом встановлювалися MySQL, Postfix, Dovecot, OpenSSL та допоміжні інструменти.

Під час налаштування MySQL задавався пароль адміністративного користувача бази даних.

Для Postfix обирався режим інтернет-сайту, а системним поштовим іменем встановлювалося повне доменне ім’я сервера.

Dovecot забезпечував доступ до пошти через IMAP і POP3. Додаткові модулі дозволяли працювати з базою даних та правилами сортування повідомлень.

В оригінальній схемі MySQL відкривалася для прослуховування на всіх мережевих інтерфейсах. На сучасному сервері цього не слід робити без міжмережевого екрана, обмеження дозволених адрес і захищеного каналу. Для більшості сайтів достатньо локального доступу до бази.

Фільтрація спаму та вірусів

Для перевірки пошти встановлювалися Amavis, SpamAssassin і ClamAV.

SpamAssassin аналізував повідомлення на характерні ознаки спаму. ClamAV перевіряв листи та вкладення на наявність шкідливого вмісту. Amavis зв’язував ці компоненти з Postfix і передавав їм повідомлення для перевірки.

Окрему службу SpamAssassin можна було зупинити, оскільки її функції використовувалися через Amavis. Це дозволяло трохи зменшити споживання оперативної пам’яті.

Веб-сервер, PHP і phpMyAdmin

Оригінальний варіант інструкції розглядав сервер на Apache з PHP 5, FastCGI, suEXEC, модулями SSL, Rewrite та іншими компонентами.

PHP використовувався для запуску сайтів і самої панелі ISPConfig. Додатково встановлювалися модулі для роботи з MySQL, графікою, поштою, шифруванням і архівами.

phpMyAdmin надавав браузерний інтерфейс для керування базами даних. Через нього можна було створювати таблиці, виконувати SQL-запити, імпортувати резервні копії та керувати користувачами.

Для прискорення PHP у ті роки використовували XCache. Він зберігав скомпільований код у пам’яті. У сучасних версіях PHP цю функцію переважно виконує OPcache.

FTP і дискові квоти

Для FTP-доступу встановлювався PureFTPd із підтримкою користувачів MySQL.

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

Оскільки звичайний FTP передає пароль і дані у відкритому вигляді, додатково налаштовувалося шифрування TLS. Для цього створювався SSL-сертифікат і обмежувалися права доступу до його приватного ключа.

Для контролю дискового простору активувалися користувацькі та групові квоти. Вони дозволяли ISPConfig обмежувати, скільки місця може використовувати конкретний сайт або обліковий запис.

DNS і статистика

Для обслуговування DNS-зон встановлювався BIND. Через нього ISPConfig могла створювати записи доменів, піддоменів, поштових серверів та інших служб.

Для збору статистики використовувалися Vlogger, Webalizer і AWStats. Вони обробляли журнали веб-сервера та формували звіти про відвідування сайтів.

Jailkit застосовувався для ізоляції SSH-користувачів. Його потрібно було встановлювати до ISPConfig, оскільки пізніше панель вже не могла повноцінно інтегрувати його в готову систему.

Веб-пошта

Для роботи з поштою через браузер встановлювався SquirrelMail.

У налаштуваннях вибирався Dovecot як IMAP-сервер. Після збереження конфігурації користувачі могли відкривати свої поштові скриньки без окремої поштової програми.

Сьогодні SquirrelMail вважається застарілим рішенням. На нових серверах частіше використовують сучасні веб-клієнти, наприклад Roundcube.

Роль ISPConfig 3

Після встановлення всіх необхідних компонентів ISPConfig об’єднувала їх у спільну систему керування.

Адміністратор отримував можливість:

створювати клієнтів і користувачів;

додавати сайти та піддомени;

керувати базами даних;

створювати FTP-акаунти;

налаштовувати поштові домени та скриньки;

редагувати DNS-зони;

встановлювати дискові квоти;

керувати статистикою;

ізолювати користувачів;

контролювати основні серверні служби.

Головною перевагою було те, що більшість повсякденних операцій виконувалася через браузер, без ручного редагування десятків конфігураційних файлів.

Безпека за сучасними вимогами

Описана конфігурація відображає практику початку минулого десятиліття. Для сучасного сервера її потрібно суттєво переглянути.

Необхідно використовувати підтримувану LTS-версію Ubuntu, актуальні PHP, MariaDB або MySQL, веб-сервер, поштові служби та свіжу версію ISPConfig.

Також потрібно:

закрити невикористовувані порти;

налаштувати UFW або інший міжмережевий екран;

захистити SSH ключами;

заборонити прямий вхід root;

увімкнути Fail2ban;

використовувати сучасні TLS-сертифікати;

регулярно оновлювати систему;

зберігати резервні копії поза сервером;

не відкривати MySQL для всього інтернету;

не вимикати AppArmor без обґрунтованої причини;

контролювати права файлів і каталогів.

Підсумок

Ubuntu Server 12.04 LTS та ISPConfig 3 дозволяли створити повноцінну платформу для самостійного хостингу сайтів, пошти, FTP, DNS і баз даних.

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

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