paano i-install ang Webmin sa Ubuntu 24.04

Ang iyong bubuuin

Ang Webmin ay isang web control panel na nagbibigay ng browser front end para sa buong Linux server — users, packages, cron jobs, firewall, Apache, BIND, disks, at iba pang daan-daang modules — na naa-access via HTTPS sa port 10000. Ang installation ay binubuo ng tatlong commands at tumatagal ng humigit-kumulang isang minuto. Ang dahilan kung bakit nakatuon ang karamihan ng gabay na ito sa ikalawang bahagi ay dahil ang Webmin ay nag-lalog in bilang root at kayang gawin ang lahat ng kayang gawin ng root. Ang isang Webmin na walang security o walang authentication ay hindi lamang "isang risk na dapat i-manage"; ito ay isang full server compromise na may login page sa harap nito. Kaya i-install ito sa loob ng sampung minuto, at gamitin ang natitirang oras para siguraduhin na ikaw lang ang makaka-access dito.

Mga Prerequisites at isang babala

Kailangan ng bagong Ubuntu 24.04 KVM VPS na may root o sudo user. Ang Webmin ay nakabase sa Perl at magaan — sapat na ang 1 GB ng RAM at gumagamit lamang ng mas mababa sa 250 MB kapag idle. Nakikinig ito sa TCP 10000 gamit ang sarili nitong bundled web server (miniserv.pl), hindi Apache o nginx, kaya hindi kailangang mag-install ng iba pang software.

May dalawang bagay na dapat pagpasyahan bago magsimula. Una, ang account na gagamitin sa pag-log in: Nag-a-authenticate ang Webmin sa mga Unix account gamit ang PAM, kaya mag-log in bilang root o isang user sa sudo group gamit ang Unix password ng account na iyon. Ang mga cloud image ay karaniwang key-only at walang password ang default user, at hindi makakapag-log in ang Webmin sa isang account na walang password. Mag-set muna ng password gamit ang sudo passwd youruser, kung hindi ay mabibigo ang login anuman ang i-type mo.

Pangalawa, ito ang babala: huwag basta-basta magbubukas ng port 10000 sa internet. Magdesisyon na ngayon kung gagamit ka ng SSH tunnel para ma-access ang Webmin (rekomendado, walang exposed na port) o ililimitahan ito sa sarili mong IP. Ang desisyong ito ang magdidikta sa lahat ng susunod na hakbang, kaya basahin ang dalawang opsyon bago galawin ang firewall.

I-install ang Webmin mula sa official repository

Naglalathala ang Webmin ng isang signed apt repository. Idinaragdag ng setup script ang repo at ang GPG signing key nito para ang mga susunod na apt upgrade runs ay kumuha ng Webmin gaya ng ibang package. Sa paraang ito, makakakuha ka ng authenticated updates sa halip na isang downloaded .deb na hindi nagpa-patch sa sarili nito.

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

Ipi-print ng script ang mga gagawin nito at magtatanong ng Setup repository? (y/N) — sagutin ang y. Kapag tapos na, i-install ang package. Ginagamit ng --install-recommends flag ang common Perl at SSL module dependencies para hindi magkaroon ng missing-library errors ang mga individual modules sa hinaharap.

sudo apt-get install --install-recommends webmin

Binago na ng Webmin ang pangalan ng script na ito noon — ang mga lumang guide ay tumutukoy sa setup-repos.sh — kaya kung ang raw URL ay nagbabalik ng 404, kunin ang kasalukuyang one-liner mula sa webmin.com/download sa halip na gumamit ng lumang pangalan. Ang tamang installation ay nagtatapos sa linyang gaya ng Webmin install complete. You can now login to https://your-host:10000/ as root. Ang service ay enabled at running, ang config ay nasa ilalim ng /etc/webmin, ang mga request ay naka-log sa /var/webmin/miniserv.log, at ang mga failed logins ay napupunta sa syslog — sa Ubuntu 24.04, sa systemd journal.

I-confirm na up at listening na ito bago magbukas ng browser:

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

Kailangan mo ng active (running) status at isang linya na nagpapakita na ang miniserv.pl ay bound sa 0.0.0.0:10000 — ang address na ito ay magiging 127.0.0.1:10000 kapag ginamit na ang tunnel route sa ibaba. Kung walang ipinapakita ang ss sa 10000, hindi nag-start ang Webmin; basahin ang journalctl -u webmin -n 50 bago magpatuloy.

Unang login, at ang certificate warning

I-point ang iyong browser sa https://YOUR_SERVER_IP:10000. Dalawang bagay ang mangyayari sa bagong install na system.

Kung active ang ufw — ang default Ubuntu server image ay inactive ito, pero maraming provider ang naka-enable na ito — hindi maglo-load ang page, na tatalakayin sa failure modes sa ibaba. Kung bukas ang port, magpapakita ang browser ng full-page block: "Your connection is not private" na may code na NET::ERR_CERT_AUTHORITY_INVALID sa Chrome, o SEC_ERROR_UNKNOWN_ISSUER / "Warning: Potential Security Risk Ahead" sa Firefox. Normal lang ito at hindi ito isang attack. Nag-generate ang Webmin ng self-signed certificate noong installation time (/etc/webmin/miniserv.pem), at dahil walang certificate authority na nagpapatunay dito, hindi ito agad pinagkakatiwalaan ng browser. Encrypted pa rin ang connection; hindi lang ito verified. I-click muna ang (Advanced, tapos Proceed) — papalitan natin ang certificate na ito nang maayos sa susunod na bahagi.

Mag-log in gamit ang root o ang iyong sudo user at Unix password, at mapupunta ka sa System Information dashboard. Isang karaniwang pagkakamali rito ay ang pag-type ng http:// sa halip na https://. Ang miniserv ay sumasagot ng plain HTTP sa port na iyon gamit ang text na "This web server is running in SSL mode. Try the URL https://..." — ang solusyon ay palitan lang ang http ng https sa address bar.

Ang security decision: paano mo ia-access ang Webmin?

Ito ang pinakamahalagang bahagi. Ang isang panel na may root-equivalent access ay hindi dapat nakalantad sa open internet para sa mga login attempt mula sa mga scanner sa buong mundo. Mayroon kang dalawang opsyon, ayon sa pagkakasunod-sunod ng preference.

Ang SSH tunnel sa Option B ang mas mainam dahil wala itong inilalantad na kahit ano. Ang IP allowlist sa Option A ay katanggap-tanggap kung ang iyong address ay static. Ang hindi paggawa sa alinman sa dalawa ay ang pagkakamaling nais iwasan ng guide na ito. Kung mas gusto mong i-access ang Webmin sa pamamagitan ng private network, ilagay ang server sa likod ng isang self-hosted WireGuard VPN at i-bind ang Webmin sa tunnel address sa halip na sa public address.

Option A: i-restrict ang Webmin sa iyong IP

Sa panel, buksan ang Webmin, pagkatapos ay Webmin Configuration, tapos IP Access Control. Piliin ang "Only allow from listed addresses" at ilagay ang iyong public IP. Makukuha mo ito sa pagtakbo ng curl ifconfig.me sa iyong laptop. I-save ang settings. Isusulat ito ng Webmin sa allow= line sa /etc/webmin/miniserv.conf at magre-restart ang service.

Ang panganib: kung dynamic ang iyong home IP at nagbago ito, o kung nagkamali ka sa pag-type ng address, ma-lo-lockout ka. Magpapakita ang browser ng "Access denied for <your IP>" at walang login form; wala ring paraan para makabalik via web. Maaari itong ayusin mula sa server console gamit ang SSH o ang VNC ng iyong provider:

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

Ang pag-delete sa allow= line ay magbabalik ng bukas na access. Gamitin lamang ito para sa recovery, at agad na magtakda ng tamang value pagkatapos.

Option B: i-bind sa localhost at i-tunnel via SSH (recommended)

Mas mabuti kaysa sa anumang allowlist ang hindi pag-listen sa public interface. I-set ang miniserv na mag-bind lamang sa loopback, pagkatapos ay i-access ito gamit ang encrypted SSH tunnel na pinagkakatiwalaan mo na.

I-edit ang /etc/webmin/miniserv.conf at idagdag o palitan ang isang linya:

bind=127.0.0.1

I-restart gamit ang sudo systemctl restart webmin. Hindi na ma-a-access ang Webmin mula sa internet — walang makikita ang port scan sa 10000, at ang ss check kanina ay magpapakita na naka-bind ito sa 127.0.0.1:10000. Mula sa iyong laptop, magbukas ng tunnel:

ssh -L 10000:localhost:10000 youruser@YOUR_SERVER_IP

Hayaan na bukas ang session na iyon at i-browse ang https://localhost:10000. Ang traffic ay dumadaan sa loob ng SSH, na authenticated na ng iyong key at encrypted, kaya ligtas na tanggapin ang self-signed certificate dito — ang SSH layer ang gumagawa ng tunay na proteksyon. Isara ang SSH session at mawawala na ang Webmin. Walang kailangang i-allowlist, walang exposed, at walang extra service na kailangang i-harden.

Kung i-set mo ang bind=127.0.0.1 at makalimutan ang tunnel, hihinto na ang remote access — iyon ang tamang function nito, hindi ito error. I-recover ito sa parehong paraan gaya ng Option A: mula sa console, tanggalin ang bind na linya o i-set ang bind=0.0.0.0, pagkatapos ay i-restart. Ito ang parehong tunnelling habit na gagamitin mo para ma-access ang isang remote development box na tumatakbo ng Claude Code sa tmux — isang SSH session, lahat ay private, at walang extra na nakikinig sa public interface.

Palitan ang self-signed certificate ng totoong certificate

Kung naka-expose ang Webmin sa isang hostname sa ilalim ng Option A, alisin ang browser warning gamit ang totoong Let's Encrypt certificate. Kailangan mo ng DNS name — halimbawa panel.example.com — na may A record na nakaturo sa server, at isang service na sumasagot sa port-80 HTTP challenge habang nagve-validate.

Built-in na ito sa Webmin: Webmin, pagkatapos ay Webmin Configuration, pagkatapos ay SSL Encryption, pagkatapos ay ang Let's Encrypt tab. I-enter ang hostname, ituro ang "website root directory" sa isang path na sineserbisyo sa port 80 para sa domain na iyon, at mag-request. Kukunin ng Webmin ang certificate, i-a-update ang certfile= at keyfile= na mga linya sa miniserv.conf para sa iyo, at i-re-renew ito nang awtomatiko bago ito mag-expire. I-reload ang page at mawawala na ang padlock warning.

Ang tanging problema: Ang mismong server ng Webmin ay tumatakbo sa 10000, hindi sa 80, kaya ang http-01 challenge ay nangangailangan ng totoong web server — Apache o nginx — na sumasagot para sa panel.example.com sa port 80, o kaya ay DNS-based validation. Sa isang Webmin-only na server na walang tumatakbo sa port 80, mag-e-error ang request dahil sa validation error hangga't hindi nabibigyan ang Let's Encrypt ng paraan para ma-access ang challenge file. Ang mekanismo — DNS records, port-80 challenge, at renewal — ay katulad ng pag-issue ng certificate para sa anumang website. Kung kailangan mo ang detalyeng iyon, ang Let's Encrypt TLS certificates with Certbot and nginx guide ay nagpapaliwanag ng validation flow at DNS setup nang detalyado. Kung ginamit mo ang SSH-tunnel na paraan, maaari mong laktawan ang section na ito: ayos lang ang self-signed certificate sa loob ng SSH, at ang totoong certificate na naka-issue para sa panel.example.com ay magbibigay lamang ng name-mismatch warning kapag binisita ang https://localhost:10000.

I-on ang two-factor authentication

Masyadong mahina ang password lang para protektahan ang root panel, kaya magdagdag ng second factor. Buksan ang Webmin, pagkatapos ay Webmin Configuration, tapos Two-Factor Authentication. Piliin ang Google Authenticator provider — standard TOTP ito, kaya gumagana ito sa Authy, 1Password, o anumang authenticator app — at i-save. I-install ng Webmin ang kailangang Perl module (Authen::OATH plus isang QR generator) at i-enable ang feature; ang hakbang na ito ay hindi pa nagbibigay ng proteksyon sa anumang account.

Pagkatapos, i-enroll ng bawat account ang sarili nitong device. Kapag enabled na ang 2FA, buksan ang Webmin, pagkatapos ay Webmin Users, piliin ang account, piliin ang Enable Two-Factor For User, at magpapakita ang Webmin ng QR code; i-scan ito gamit ang app at i-enter ang isang generated code para mag-confirm. Mula noon, hihingin ng login ang six-digit token pagkatapos ng password. Mag-enroll bago mag-log out — kung required ang 2FA pero hindi pa na-scan ng account ang code, maaari mo pa ring tanggalin ang requirement mula sa console, pero mas madali kung mag-e-enroll muna.

Idagdag ang Fail2ban para i-ban ang brute-force logins

Dapat i-punish ang paulit-ulit na failed logins kahit sa mga restricted login endpoint. Ipinapasa ng Webmin ang mga failed logins sa syslog sa anyong webmin[12345]: Invalid login as root from 10.0.0.9, o Non-existent login as ... para sa username na hindi Unix account — sa Ubuntu 24.04, ang mga linyang ito ay napupunta sa systemd journal dahil walang /var/log/auth.log ang stock image. May kasamang stock webmin-auth filter ang Fail2ban na tumutugma sa dalawang linyang ito. Ang jail sa ibaba ay nagse-set ng backend = systemd nang kusa, kaya hindi na kailangan ng custom regex o log path.

I-create ang /etc/fail2ban/jail.d/webmin.local:

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

I-reload gamit ang sudo systemctl restart fail2ban, pagkatapos ay i-confirm kung live na ang jail:

sudo fail2ban-client status webmin-auth

Dapat makita ang jail sa listahan na may ban counter na zero sa simula (sa journal backend, walang File list: line). Para ma-verify ang koneksyon, sadyang mag-fail ng login nang ilang beses mula sa ibang network, pagkatapos ay i-run muli ang status command at obserbahan ang pagtaas ng Currently banned. Kung hindi ito gumagalaw, siguraduhing hindi ka nagte-test mula sa address na nasa ignoreip ng Fail2ban, at i-run ang journalctl SYSLOG_IDENTIFIER=webmin sa server para i-confirm kung ang mga Invalid login line ay talagang sinusulat. Kung hindi pa naka-install ang Fail2ban sa machine na ito, ang Fail2ban on Ubuntu 24.04 for SSH guide ay nagpapaliwanag ng installation at ng SSH jail na dapat mong i-run kasabay nito.

Limit ang access ng bawat Webmin user

Hindi lahat ng gumagamit ng panel ay kailangang may root access sa lahat ng bagay. Sa ilalim ng Webmin, tapos Webmin Users, gumawa ng mga karagdagang Webmin login at bigyan ang bawat isa lamang ng mga kailangang module — halimbawa, isang backups operator na ang nakikita lang ay ang cron at filesystem modules. Kapag nag-edit ng user, makikita ang checklist ng lahat ng module; kapag tinanggal ang check sa isa, mawawala ito sa menu ng user at iba-block ang mga kaukulang URL. Ito ay defence in depth: kahit manakaw ang isang low-privilege Webmin session, hindi nito maaaring i-rewrite ang /etc/shadow kung wala ang Users module sa listahan nito.

Pagpapanatili ng updated na Webmin

Dahil nag-install ka mula sa apt repository, kukunin ng sudo apt update && sudo apt upgrade ang mga bagong release ng Webmin kasabay ng iba pang bahagi ng system. Mag-patch agad — madalas maging target ang mga control panel. Maaari ring mag-update ang Webmin sa pamamagitan ng Webmin, pagkatapos ay Webmin Configuration, tapos Upgrade Webmin, ngunit mas malinis ang apt path sa Ubuntu dahil pinapanatili nitong consistent ang mga version sa iyong iba pang package management. Huwag itong balewalain: ang ilang nakaraang Webmin CVEs ay mga remote-code-execution bug, at ang tanging pagkakaiba ng "patched" sa "compromised" ay kung gaano kabilis isinagawa ng admin ang upgrade.

Failure modes, kasama ang mga string na makikita mo

"Your connection is not private" / NET::ERR_CERT_AUTHORITY_INVALID. Lalabas ito sa unang load. Sanhi: ang self-signed certificate na ginawa ng Webmin noong installation ay walang trusted issuer. Hindi ito attack; encrypted ang channel, hindi lang ito verified. Fix: ituloy muna ang pag-proceed sa warning, pagkatapos ay mag-issue ng totoong Let's Encrypt certificate, o i-accept na lang ito nang permanente kung gagamit ka ng SSH tunnel para ma-access ang Webmin.

"This web server is running in SSL mode. Try the URL https://..." Na-type mo ang http://server:10000. Ang miniserv ay TLS lang ang protocol sa port na iyon at ipinapaalam ito sa iyo sa plain text. Fix: palitan ang http ng https sa address bar.

Page times out — ERR_CONNECTION_TIMED_OUT / "This site can't be reached". Hindi nakakarating ang request sa Webmin. Sa Ubuntu, madalas na sanhi nito ang pag-drop ng ufw sa port 10000. I-verify gamit ang sudo ufw status; kung hindi nakalista ang 10000, buksan ito gamit ang sudo ufw allow 10000/tcp o, mas mabuti, iwanan itong sarado at gamitin ang SSH tunnel mula sa Option B. Tandaan ang pagkakaiba: ang timeout ay nangangahulugang tahimik na nag-i-drop ng packets ang firewall, habang ang ERR_CONNECTION_REFUSED naman ay nangangahulugang reachable ang port pero hindi tumatakbo ang Webmin — i-check ang sudo systemctl status webmin.

"Access denied for <your IP>." Nag-set ka ng IP Access Control sa ilalim ng Option A at ang kasalukuyang address mo ay wala sa allow list — maaaring nagbago ang dynamic IP o may typo. Walang paraan para makabalik sa pamamagitan ng browser. Fix mula sa console: i-edit ang allow= line sa /etc/webmin/miniserv.conf, itama o burahin ito, at i-run ang sudo systemctl restart webmin.

"Login failed. Please try again." gamit ang credentials na alam mong tama. Ang account ay walang Unix password, na standard sa mga key-only cloud images. Nag-a-authenticate ang Webmin sa pamamagitan ng PAM gamit ang Unix password, at ang password na iyon ay hindi umiiral para sa user. Fix: i-run ang sudo passwd youruser sa server, pagkatapos ay mag-log in. Kung ang /var/webmin/miniserv.log ay nagpapakita ng Non-existent login as ..., ang tinatype mong username ay hindi isang Unix account.

Para sa higit sa dalawang server, mas mainam ang automation kaysa sa paglalagay ng control panel sa bawat box: your first Ansible playbook ang simula nito.

FAQ

Ligtas ba na i-expose ang Webmin sa public internet?

Ituring ang Webmin na naka-expose sa internet bilang isang root shell na may login page, dahil iyon ang katotohanan nito. Magiging sapat lang ang seguridad nito kung may mga layers: totoong certificate, two-factor authentication, Fail2ban, at alinman sa mahigpit na IP allowlist o, mas mabuti, walang public exposure. Ang setup na may pinakamababang risk ay ang pag-bind ng Webmin sa 127.0.0.1 at pag-access dito gamit ang SSH tunnel, para ang port 10000 ay hindi sasagot sa sinuman sa open internet.

Paano ko maaalis ang Webmin certificate warning?

Lalabas ang warning (NET::ERR_CERT_AUTHORITY_INVALID) dahil ang Webmin ay may kasamang self-signed certificate. Mag-issue ng totoong certificate mula sa Webmin, Webmin Configuration, SSL Encryption, Let's Encrypt, gamit ang DNS name na nakaturo sa server na may nagsisilbi para sa port-80 challenge para sa validation. Kung sa SSH tunnel lang sa localhost mo ina-access ang Webmin, walang panganib ang warning — dahil ang SSH ay nag-e-encrypt at nag-a-authenticate na ng connection — kaya ligtas na i-accept ang self-signed certificate.

Paano ko malilimitahan ang Webmin sa aking IP address lamang?

Pumunta sa Webmin, Webmin Configuration, IP Access Control, piliin ang "Only allow from listed addresses", at ilagay ang iyong public IP mula sa curl ifconfig.me. Itinatago ito ng Webmin sa allow= line ng /etc/webmin/miniserv.conf. Mag-ingat sa dynamic home IP: kung magbago ito, ma-lo-lockout ka at kailangang ayusin ang allow= line mula sa server console, kaya mas reliable sa praktikal na gamit ang static address o ang SSH-tunnel method.

Bakit nabigo ang login kahit tama ang password?

Nag-a-authenticate ang Webmin sa pamamagitan ng PAM laban sa iyong Unix password. Ang mga cloud images ay karaniwang key-only at walang password na naka-set sa default account — kaya walang ma-ma-match ang PAM at tatanggihan ang login. Patakbuhin ang sudo passwd youruser sa server para mag-set ng password, pagkatapos ay mag-log in. Ang isang Non-existent login as ... line sa /var/webmin/miniserv.log ay nangangahulugang ang username mismo ay hindi isang totoong Unix account.

Ano ang gamit ng Webmin kumpara sa plain SSH?

Ang Webmin ay isang layer para sa discoverability at convenience. Kapaki-pakinabang ito para sa pag-browse ng mga log file, pag-manage ng mga user at cron, pag-edit ng firewall rules, at pagtingin sa disk at service state nang hindi kinakailangang kabisaduhin ang bawat command — mainam ito para sa mga occasional admins o mixed-skill teams. Ang plain SSH ay mas mabilis, scriptable, at mas maliit ang attack surface para sa mga routine na trabaho. Maraming admin ang gumagamit ng pareho: SSH para sa pang-araw-araw na gamit, at Webmin na naka-bind sa localhost sa likod ng isang tunnel para sa mga paminsan-minsang point-and-click na trabaho.