Як встановити й захистити Webmin на Ubuntu 24.04

Що ви створюєте

Webmin — це вебпанель керування, яка надає браузерний інтерфейс до всього Linux-сервера: користувачів, пакетів, cron-завдань, брандмауера, Apache, BIND, дисків і сотень інших модулів. Доступ до неї здійснюється через HTTPS на порту 10000. Встановлення складається з трьох команд і займає приблизно хвилину. Цей посібник приділяє більшу частину обсягу другій половині, оскільки Webmin входить у систему як root і може виконувати будь-які дії, доступні root. Відкритий для всіх або неавтентифікований Webmin — це не просто «ризик, яким потрібно керувати». Це повна компрометація сервера зі сторінкою входу перед нею. Тому встановіть його за десять хвилин, а решту години витратьте на те, щоб переконатися: доступ до нього маєте лише ви.

Передумови та важливе попередження

Потрібен новий Ubuntu 24.04 KVM VPS із root або користувачем із правами sudo. Webmin написаний на Perl і не потребує багато ресурсів: 1 GB RAM достатньо, а в режимі простою він використовує значно менше чверті GB. Webmin прослуховує TCP-порт 10000 через власний вбудований вебсервер (miniserv.pl), а не через Apache або nginx, тому спочатку нічого іншого встановлювати не потрібно.

Перед початком потрібно визначити два моменти. По-перше, обліковий запис, під яким ви входитимете: Webmin автентифікує Unix-облікові записи через PAM, тому вхід виконується як root або як користувач із групи sudo, використовуючи Unix-пароль цього облікового запису. У cloud-образах зазвичай використовується вхід лише за ключем, а для стандартного користувача пароль не встановлено. Webmin не може виконати вхід до облікового запису без пароля. Спочатку встановіть пароль за допомогою sudo passwd youruser, інакше вхід не відбудеться незалежно від введеного пароля.

По-друге, важливе попередження: не відкривайте порт 10000 для всього інтернету, залишаючи його без додаткового захисту. Заздалегідь вирішіть, чи підключатиметеся до Webmin через SSH-тунель (рекомендовано, без відкритих назовні портів), чи обмежите доступ власною IP-адресою. Це рішення визначає всі наведені нижче кроки, тому перед налаштуванням firewall ознайомтеся з обома варіантами.

Встановіть Webmin з офіційного репозиторію

Webmin публікує підписаний apt-репозиторій. Скрипт налаштування додає репозиторій і його ключ підпису GPG, тому майбутні запуски apt upgrade отримують Webmin як будь-який інший пакет. Ви отримуєте автентифіковані оновлення, а не завантажений .deb, який більше не оновлюється автоматично.

curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
sudo sh webmin-setup-repo.sh

Скрипт виводить заплановані дії та запитує Setup repository? (y/N). Введіть y. Після завершення встановіть пакет. Прапорець --install-recommends встановлює поширені залежності Perl і модулі SSL, щоб окремі модулі пізніше не завершувалися помилками через відсутні бібліотеки.

sudo apt-get install --install-recommends webmin

Webmin уже перейменовував цей скрипт. У старіших інструкціях згадується setup-repos.sh. Якщо вихідна URL-адреса повертає 404, отримайте поточну однорядкову команду безпосередньо зі сторінки webmin.com/download, а не фіксуйте назву скрипту. Успішне встановлення завершується рядком на кшталт Webmin install complete. You can now login to https://your-host:10000/ as root. Сервіс увімкнено та запущено, конфігурація зберігається в /etc/webmin, запити записуються до /var/webmin/miniserv.log, а невдалі входи — до syslog, в Ubuntu 24.04 — до журналу systemd.

Перш ніж відкривати браузер, переконайтеся, що сервіс справді запущений і прослуховує порт:

sudo systemctl status webmin --no-pager
sudo ss -tlnp | grep 10000

Потрібен статус active (running) і рядок, який показує, що miniserv.pl прослуховує на 0.0.0.0:10000. Після переходу на тунель нижче ця адреса зміниться на 127.0.0.1:10000. Якщо ss не показує нічого на порту 10000, Webmin не запустився. Перш ніж продовжувати, прочитайте journalctl -u webmin -n 50.

Перший вхід і попередження про сертифікат

Укажіть у браузері адресу https://YOUR_SERVER_IP:10000. На щойно налаштованому сервері відбуваються дві речі.

Якщо активний ufw, сторінка взагалі не завантажиться. Власний образ сервера Ubuntu постачається з неактивним ufw, але багато провайдерів вмикають його заздалегідь. Цей випадок описано нижче в розділі про типові помилки. Якщо порт відкритий, браузер блокує сторінку та показує повідомлення "Your connection is not private" з кодом NET::ERR_CERT_AUTHORITY_INVALID у Chrome або SEC_ERROR_UNKNOWN_ISSUER / "Warning: Potential Security Risk Ahead" у Firefox. Це очікувана поведінка, а не ознака зламу. Під час інсталяції Webmin створює самопідписаний сертифікат (/etc/webmin/miniserv.pem). Оскільки цей сертифікат не підтверджений центром сертифікації, браузер не довіряє йому автоматично. З’єднання все одно зашифроване, але його справжність не підтверджена. Тимчасово натисніть Advanced, а потім Proceed. Нижче ми належним чином замінимо цей сертифікат.

Увійдіть за допомогою root або свого користувача sudo і його пароля Unix. Після цього відкриється панель System Information. Поширена помилка — ввести http:// замість https://. miniserv відповідає на цьому порту звичайним HTTP і повертає точний текст "This web server is running in SSL mode. Try the URL https://...". Щоб виправити це, достатньо змінити http на https в адресному рядку.

Рішення щодо безпеки: як ви підключатиметеся до Webmin?

Тепер — найважливіша частина. Панель із повноваженнями, еквівалентними root, не повинна бути відкритою в Інтернеті та приймати спроби входу від усіх сканерів у світі. Є два обґрунтовані варіанти, розташовані в порядку переваги. Кожен self-hosted інтерфейс адміністрування порушує це саме питання. Тому безпека Vaultwarden залежить від його адміністративної кінцевої точки та файлу резервної копії, а не від шифрування.

SSH-тунель у варіанті B кращий, оскільки він взагалі нічого не відкриває назовні. Список дозволених IP-адрес у варіанті A прийнятний, якщо ваша адреса статична. Не використовувати жоден із цих варіантів — саме та помилка, якій має запобігти весь цей посібник. Якщо ви хочете підключатися до Webmin через приватну мережу, а не одним із цих способів, розмістіть сервер за self-hosted VPN на базі WireGuard і прив’яжіть Webmin до адреси тунелю, а не до публічної адреси.

Варіант A: обмежити Webmin для своєї IP-адреси

У панелі відкрийте Webmin, потім Webmin Configuration, потім IP Access Control. Виберіть "Only allow from listed addresses" і введіть свою публічну IP-адресу. Її можна дізнатися, виконавши curl ifconfig.me на ноутбуці. Збережіть зміни. Webmin записує це в рядок allow= у файлі /etc/webmin/miniserv.conf і перезапускає себе.

Проблема виникає, якщо домашня IP-адреса динамічна й змінюється або якщо ви помилилися під час введення адреси. У такому разі ви втратите доступ. У браузері з’явиться повідомлення "Access denied for <your IP>" без форми входу, і відновити доступ через вебінтерфейс не вдасться. Виправте налаштування з консолі сервера через SSH або VNC вашого провайдера:

sudo nano /etc/webmin/miniserv.conf
# find the line that begins  allow=
# correct your IP, or delete the whole line to allow all again
sudo systemctl restart webmin

Видалення рядка allow= знову відкриває доступ для всіх. Видаляйте його лише для відновлення доступу, а потім негайно вкажіть правильне значення.

Варіант B: прив’язка до localhost і тунелювання через SSH (рекомендовано)

Краще за будь-який список дозволів — взагалі не прослуховувати публічний інтерфейс. Налаштуйте miniserv на прив’язку лише до loopback, а потім підключайтеся до нього через зашифрований SSH-тунель, якому ви вже довіряєте.

Відредагуйте /etc/webmin/miniserv.conf і додайте або змініть один рядок:

bind=127.0.0.1

Перезапустіть за допомогою sudo systemctl restart webmin. Тепер Webmin недоступний з інтернету, сканування порту 10000 нічого не знаходить, а перевірка ss з попереднього розділу показує прив’язку до 127.0.0.1:10000. На ноутбуці відкрийте тунель:

ssh -L 10000:localhost:10000 youruser@YOUR_SERVER_IP

Не закривайте цю сесію та відкрийте https://localhost:10000. Трафік проходить усередині SSH. SSH уже автентифіковано вашим ключем і зашифровано, тому тут можна безпечно прийняти самопідписаний сертифікат: фактичний захист забезпечує рівень SSH. Після закриття SSH-сесії Webmin зникає з доступу. Не потрібно налаштовувати список дозволів, нічого не відкрито назовні, не потрібно додатково захищати окремий сервіс.

Якщо ви налаштуєте bind=127.0.0.1 і забудете про тунель, віддалений доступ просто припиниться. Це нормальна робота функції, а не несправність. Відновіть доступ так само, як у варіанті A: з консолі видаліть рядок bind або встановіть bind=0.0.0.0, а потім перезапустіть сервіс. Це та сама схема тунелювання, яку ви використовували б для доступу до віддаленого середовища розробки з Claude Code у tmux: одна SSH-сесія, усе приватне, жоден додатковий сервіс не прослуховує публічний інтерфейс.

Замініть самопідписаний сертифікат на справжній

Якщо за Option A ви відкриваєте Webmin на хості, усуньте попередження браузера за допомогою справжнього сертифіката Let's Encrypt. Потрібне DNS-ім’я, наприклад panel.example.com, з A-записом, що вказує на сервер, а також вебсервер, який під час перевірки відповідає на HTTP-запит на порту 80.

Цю функцію вбудовано у Webmin: Webmin, потім Webmin Configuration, потім SSL Encryption, потім вкладка Let's Encrypt. Введіть ім’я хоста, укажіть у полі "website root directory" шлях, який обслуговується через порт 80 для цього домену, і надішліть запит. Webmin отримає сертифікат, самостійно оновить рядки certfile= і keyfile= у miniserv.conf та автоматично поновлюватиме сертифікат до завершення строку його дії. Перезавантажте сторінку — попередження зникне, а значок замка буде без помилок.

Є важливе обмеження: власний сервер Webmin працює на порту 10000, а не на 80. Тому для перевірки http-01 потрібен справжній вебсервер, Apache або nginx, який відповідає для panel.example.com на порту 80. Інший варіант — скористатися перевіркою на основі DNS. На сервері, де працює лише Webmin і на порту 80 немає служби, запит завершиться помилкою перевірки, доки ви не забезпечите Let's Encrypt доступ до файлу перевірки. Механізм, DNS-записи, перевірка через порт 80 і поновлення сертифіката такі самі, як під час випуску сертифіката для будь-якого вебсайту. Докладний опис процесу перевірки та налаштування DNS наведено в посібнику зі створення TLS-сертифікатів Let's Encrypt за допомогою Certbot і nginx. Якщо ви використали варіант із SSH-тунелем, цей розділ можна повністю пропустити: самопідписаний сертифікат достатній за використання SSH, а справжній сертифікат, виданий для panel.example.com, однаково спричинятиме попередження про невідповідність імені під час переходу на https://localhost:10000.

Увімкнення двофакторної автентифікації

Одного пароля недостатньо для захисту панелі root, тому додайте другий фактор. Відкрийте Webmin, потім Webmin Configuration, потім Two-Factor Authentication. Виберіть постачальника Google Authenticator. Це стандартний TOTP, тому він працює з Authy, 1Password або будь-яким застосунком-автентифікатором. Збережіть налаштування. Webmin встановить потрібний невеликий модуль Perl (Authen::OATH і генератор QR-кодів) та ввімкне функцію. Цей крок сам по собі ще не захищає жоден обліковий запис.

Після цього кожен обліковий запис реєструє власний пристрій. Коли 2FA увімкнено, відкрийте Webmin, потім Webmin Users, виберіть обліковий запис і натисніть Enable Two-Factor For User. Webmin покаже QR-код. Відскануйте його за допомогою застосунку та введіть один згенерований код для підтвердження. Відтепер під час входу після пароля потрібно буде вводити шестизначний токен. Виконайте реєстрацію до виходу із системи. Якщо 2FA вже обов’язкова, але ваш обліковий запис ще не відсканував код, вимогу все одно можна скасувати через консоль, але спочатку виконати реєстрацію значно простіше.

Додайте Fail2ban для блокування перебору паролів

Навіть обмежений endpoint для входу має блокувати повторні невдалі спроби. Webmin записує невдалі входи до syslog у форматі webmin[12345]: Invalid login as root from 10.0.0.9, а для імені користувача, яке взагалі не є обліковим записом Unix, — у форматі Non-existent login as .... В Ubuntu 24.04 ці рядки потрапляють до журналу systemd, оскільки стандартний образ не містить /var/log/auth.log. Fail2ban постачається зі стандартним фільтром webmin-auth, який точно знаходить обидва ці рядки. Наведений нижче jail сам задає backend = systemd, тому власні регулярні вирази або шлях до журналу не потрібні.

Створіть /etc/fail2ban/jail.d/webmin.local:

[webmin-auth]
enabled  = true
port     = 10000
filter   = webmin-auth
backend  = systemd
maxretry = 4
bantime  = 1h

Перезавантажте конфігурацію за допомогою sudo systemctl restart fail2ban, а потім переконайтеся, що jail працює:

sudo fail2ban-client status webmin-auth

Спочатку jail має відображатися з лічильником блокувань, що дорівнює нулю. Для backend журналу вивід не містить рядка File list:. Щоб перевірити всю схему, навмисно кілька разів виконайте невдалий вхід з іншої мережі. Потім повторно виконайте команду перевірки стану та стежте, як зростає Currently banned. Якщо лічильник не змінюється, переконайтеся, що адресу, з якої ви тестуєте, не додано до ignoreip Fail2ban. Також виконайте на сервері journalctl SYSLOG_IDENTIFIER=webmin, щоб перевірити, чи справді записуються рядки Invalid login. Якщо Fail2ban ще не встановлено на цьому сервері, у посібнику Fail2ban в Ubuntu 24.04 для SSH описано встановлення та SSH jail, який слід запустити одночасно з цим jail.

Обмежте доступ кожного користувача Webmin

Не кожному, кому потрібна панель, потрібен root-доступ до всіх функцій. У розділі Webmin, потім Webmin Users створіть додаткові облікові записи Webmin і надайте кожному лише потрібні модулі. Наприклад, оператор резервного копіювання може бачити тільки модулі cron і файлової системи. Під час редагування користувача відображається список із прапорцями для всіх модулів. Зняття прапорця прибирає модуль із меню цього користувача та блокує відповідні URL. Це додатковий рівень захисту: навіть викрадена сесія Webmin із низькими привілеями не зможе перезаписати /etc/shadow, якщо модуля Users немає в її списку.

Оновлення Webmin

Оскільки ви встановили Webmin із apt-репозиторію, sudo apt update && sudo apt upgrade завантажує нові релізи Webmin разом з іншими оновленнями системи. Встановлюйте виправлення без зволікань, оскільки панелі керування часто є ціллю атак. Webmin також можна оновити через Webmin, потім Webmin Configuration, потім Upgrade Webmin, але в Ubuntu зручніше використовувати apt, оскільки так версії залишаються узгодженими з іншими пакетами. Не вважайте це необов’язковим: кілька попередніх CVE у Webmin були вразливостями віддаленого виконання коду, і різницю між «виправлено» та «сервер зламано» визначало лише те, наскільки швидко адміністратор запускав оновлення.

Типові причини помилок і повідомлення, які ви побачите

"Your connection is not private" / NET::ERR_CERT_AUTHORITY_INVALID. Повідомлення з’являється під час першого завантаження. Причина: self-signed сертифікат, який Webmin створив під час встановлення, не має довіреного видавця. Це не атака: канал зашифрований, але його справжність не підтверджена довіреним центром сертифікації. Тимчасове рішення: пройдіть попередження, а потім випустіть справжній сертифікат Let's Encrypt або прийміть цей сертифікат назавжди, якщо підключаєтеся до Webmin через SSH-тунель.

"This web server is running in SSL mode. Try the URL https://..." Ви ввели http://server:10000. miniserv використовує на цьому порту лише TLS і повідомляє про це у відкритому тексті. Виправлення: змініть http на https в адресному рядку.

Сторінка не завантажується вчасно, ERR_CONNECTION_TIMED_OUT / "This site can't be reached". Запит не доходить до Webmin. В Ubuntu майже завжди причина полягає в тому, що ufw відкидає трафік на порт 10000. Перевірте це за допомогою sudo ufw status. Якщо порт 10000 не зазначено у виводі, відкрийте його командою sudo ufw allow 10000/tcp або, що краще, залиште закритим і скористайтеся SSH-тунелем з Option B. Важливо розрізняти ці випадки: timeout означає, що firewall мовчки відкидає пакети, а ERR_CONNECTION_REFUSED означає, що порт доступний, але Webmin не запущений. Перевірте це за допомогою sudo systemctl status webmin.

"Access denied for <your IP>." Ви налаштували IP Access Control у Option A, але поточна адреса відсутня у списку дозволених адрес. Також можливо, що динамічна IP-адреса змінилася або в адресі є помилка. Повернути доступ через браузер неможливо. Виправлення виконайте з консолі: відредагуйте рядок allow= у файлі /etc/webmin/miniserv.conf, виправте або видаліть його та виконайте sudo systemctl restart webmin.

"Login failed. Please try again." за умови, що облікові дані правильні. Обліковий запис не має пароля Unix. Це стандартна конфігурація для cloud images, де використовується лише автентифікація за ключами. Webmin автентифікує користувача через PAM за паролем Unix, але для цього користувача такого пароля немає. Виправлення: виконайте sudo passwd youruser на сервері, а потім увійдіть. Якщо /var/webmin/miniserv.log показує Non-existent login as ..., ви вводите ім’я користувача, якого взагалі немає серед облікових записів Unix.

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

FAQ

Чи безпечно відкривати Webmin у публічному інтернеті?

Сприймайте Webmin, доступний з інтернету, як root shell зі сторінкою входу, тому що саме ним він і є. Це достатньо безпечно лише за багаторівневого захисту: справжній сертифікат, двофакторна автентифікація, Fail2ban і або жорсткий список дозволених IP-адрес, або, що краще, повна відсутність публічного доступу. Найменший ризик має конфігурація, у якій Webmin прив’язаний до 127.0.0.1, а доступ до нього здійснюється через SSH-тунель. Тоді порт 10000 не приймає з’єднань із відкритого інтернету.

Як усунути попередження про сертифікат Webmin?

Попередження (NET::ERR_CERT_AUTHORITY_INVALID) з’являється тому, що Webmin постачається із самопідписаним сертифікатом. Випустіть справжній сертифікат у Webmin через Webmin Configuration, SSL Encryption, Let's Encrypt. Для перевірки використайте DNS-ім’я, яке вказує на сервер, де щось обслуговує challenge на порту 80. Якщо ви завжди підключаєтеся до Webmin через SSH-тунель до localhost, попередження не становить загрози. SSH уже шифрує та автентифікує з’єднання, тому самопідписаний сертифікат можна безпечно прийняти.

Як обмежити Webmin лише моєю IP-адресою?

Відкрийте Webmin, Webmin Configuration, IP Access Control, виберіть "Only allow from listed addresses" і введіть свою публічну IP-адресу з curl ifconfig.me. Webmin зберігає це в рядку allow= файлу /etc/webmin/miniserv.conf. Враховуйте динамічну домашню IP-адресу: якщо вона зміниться, доступ буде заблоковано. Тоді рядок allow= доведеться виправляти з консолі сервера. Тому на практиці надійнішими є статична адреса або спосіб із SSH-тунелем.

Чому вхід не працює навіть із правильним паролем?

Webmin автентифікує користувача через PAM, використовуючи пароль Unix. Водночас хмарні образи зазвичай налаштовані лише для входу за ключем, а для облікового запису за замовчуванням пароль не задано. Тому PAM не має з чим порівняти введений пароль і відхиляє вхід. Виконайте sudo passwd youruser на сервері, щоб задати пароль, а потім увійдіть. Рядок Non-existent login as ... у /var/webmin/miniserv.log означає, що саме ім’я користувача не відповідає реальному обліковому запису Unix.

Для чого потрібен Webmin порівняно зі звичайним SSH?

Webmin — це рівень зручності та зручного пошуку функцій. Він справді корисний для перегляду журналів, керування користувачами й cron, редагування правил firewall, а також перегляду стану дисків і сервісів без запам’ятовування кожної команди. Це зручно для адміністраторів, які виконують такі завдання час від часу, або команд із різним рівнем навичок. Звичайний SSH швидший, підтримує сценарії та створює значно меншу площу атаки для типових операцій. Багато адміністраторів використовують обидва варіанти: SSH для щоденної роботи, а Webmin прив’язують до localhost і відкривають через тунель для рідкісних операцій у графічному інтерфейсі. Якщо насправді вас цікавить вибір панелі, а не порівняння панелі з shell, спочатку варто розглянути Cockpit і Webmin, оскільки вони відрізняються обсягом змін, які кожен із них може вносити в систему, і способом автентифікації користувача.