पूरी तरह मैन्युअल इंस्टॉलेशन: अभी-अभी खरीदे गए VPS से लेकर चालू dashboard तक, चरण-दर-चरण।
सर्वर की तैयारी, साइट बनाना, डेटाबेस, config.php और SSL यहाँ विस्तार से दिए गए हैं।
हर सुरक्षा टूल और cron से जुड़ी कमांड
FAQ-संदर्भ में हैं, बीच-बीच में लिंक दिए गए हैं।
मुख्य नियम: SSH या फ़ायरवॉल बदलते समय अपना मौजूदा कनेक्शन बंद न करें, जब तक नए को किसी अलग विंडो में जाँच न लें। अगर फिर भी एक्सेस खो जाए — लगभग सभी होस्टिंग प्रदाता कंट्रोल पैनल में आपातकालीन कंसोल (VNC/Recovery) देते हैं।
01. Ubuntu/Debian वाला VPS खरीदा — कहाँ से शुरू करें
खरीदने के बाद होस्टिंग प्रदाता भेजता है: IP पता, यूज़रनेम (आमतौर पर root) और पासवर्ड (या SSH-कुंजी)। लॉगिन के लिए इतना काफी है। कार्रवाइयों का क्रम (हर चरण नीचे एक सेक्शन है):
SSH के ज़रिए सर्वर से कनेक्ट करें;
सिस्टम अपडेट करें, होस्टनेम और टाइमज़ोन सेट करें;
sudo अधिकारों वाला एक सामान्य यूज़र बनाएँ (root के तहत काम न करें);
SSH-कुंजी से लॉगिन सेट करें और पासवर्ड से लॉगिन बंद करें;
SSH सर्वर तक पहुँचने के लिए एक सुरक्षित टर्मिनल है। 203.0.113.10 की जगह अपना IP डालें।
203.0.113.10 एक उदाहरण है, यह पता मौजूद नहीं है (दस्तावेज़ीकरण के लिए आरक्षित)। इसे वैसे का वैसा न डालें — इसे होस्टर के ईमेल में मिले अपने सर्वर के असली IP से बदलें। वरना कनेक्शन नहीं बनेगा।
Windows 10/11: PowerShell या “Terminal” खोलें और अंतर्निहित ssh का उपयोग करें (या PuTTY / MobaXterm क्लाइंट)। macOS / Linux: “Terminal” खोलें।
# root के रूप में लॉगिन (पासवर्ड होस्टर से आया है):
ssh root@203.0.113.10
# अगर होस्टर ने पासवर्ड की जगह key फ़ाइल दी है:
ssh -i path/to/key root@203.0.113.10
पहले कनेक्शन पर SSH “authenticity of host” के बारे में पूछेगा — yes टाइप करें। टाइप करते समय पासवर्ड दिखाई नहीं देता (यह सामान्य है)। अगर होस्टर ने अस्थायी पासवर्ड दिया है — इसे passwd कमांड से बदल लें।
03. सिस्टम अपडेट और बुनियादी सेटअप
सबसे पहले — सभी पैकेज अपडेट करें और होस्टनेम व टाइमज़ोन सेट करें।
टाइमज़ोन की सूची — timedatectl list-timezones. यदि अपडेट के अंत में “Daemons using outdated libraries” वाली नीली विंडो दिखे — सभी सेवाएँ चुनें (Space) और OK दबाएँ, यह सुरक्षित है।
04. sudo अधिकार वाला उपयोगकर्ता बनाना
हमेशा root के रूप में काम करना सुरक्षित नहीं है। एक सामान्य उपयोगकर्ता बनाएँ और उसे sudo अधिकार दें (आवश्यकता होने पर एडमिन कमांड चलाना)। deploy को किसी भी नाम से बदलें।
# उपयोगकर्ता बनाएँ (पासवर्ड सेट करेगा और जानकारी पूछेगा — Enter दबा सकते हैं):
adduser deploy
# sudo समूह में जोड़ें:
usermod -aG sudo deploy
# जाँचें (root के रूप में):
su - deploy
sudo whoami # आउटपुट होना चाहिए: root
exit
आगे से सर्वर पर इसी उपयोगकर्ता के रूप में लॉग इन करें: ssh deploy@203.0.113.10, और एडमिन कमांड को sudo प्रीफ़िक्स के साथ चलाएँ।
05. SSH कुंजियाँ और पासवर्ड से लॉगिन बंद करना
कुंजी से लॉगिन पासवर्ड से ज़्यादा सुरक्षित है: पासवर्ड का अनुमान लगाया जा सकता है, कुंजी का लगभग नहीं। पहले अपने कंप्यूटर पर कुंजी बनाते हैं, उसे सर्वर पर कॉपी करते हैं, लॉगिन जाँचते हैं — और तभी पासवर्ड बंद करते हैं।
चरण 1. अपने कंप्यूटर पर कुंजी बनाएँ (Windows PowerShell / macOS / Linux):
ssh-keygen -t ed25519 -C "my-laptop"
# सभी सवालों पर Enter दबाएँ (कुंजी ~/.ssh/id_ed25519 में सहेजी जाएगी)
चरण 3.नई विंडो में कुंजी से लॉगिन जाँचें — बिना पासवर्ड के अंदर जाने देना चाहिए:
ssh deploy@203.0.113.10
जब तक कुंजी से लॉगिन जाँचा और काम करता हुआ सिद्ध न हो जाए (चरण 1–3), तब तक विकल्प B न चलाएँ, और अपना चालू सत्र बंद न करें। यह root सहित सभी उपयोगकर्ताओं के लिए पासवर्ड से लॉगिन बंद कर देता है। काम करती कुंजी के बिना सर्वर तक पहुँच पूरी तरह खो जाएगी — जिसे केवल होस्टिंग कंसोल के ज़रिए ही वापस पाया जा सकेगा। कुंजी नहीं है तो विकल्प A लें।
चरण 4. SSH पहुँच को कठोर करें। सेटिंग्स एक अलग फ़ाइल में रखते हैं, मुख्य कॉन्फ़िग को नहीं छूते। अपनी स्थिति के अनुसार विकल्प चुनें:
विकल्प A — केवल root बंद करें, पासवर्ड रहने दें। कुंजी की ज़रूरत नहीं और पहुँच नहीं खोएँगे:
विकल्प B — पूर्ण हार्डनिंग। पासवर्ड से लॉगिन बंद करें और root केवल कुंजी से रहने दें। इसे केवल तभी चलाएँ जब सुनिश्चित हो जाए कि कुंजी से लॉगिन काम कर रहा है:
sudo tee /etc/ssh/sshd_config.d/00-hardening.conf >/dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password
KbdInteractiveAuthentication no
EOF
sudo systemctl restart ssh
दोनों विकल्पों में root का पासवर्ड से लॉगिन बंद हो जाता है। PermitRootLogin no root को पूरी तरह रोकता है, और prohibit-password केवल कुंजी से लॉगिन रहने देता है (प्रशासन के लिए deploy से लॉगिन करें और sudo इस्तेमाल करें)। SSH पोर्ट बदलना हो तो Port 2222 लाइन जोड़ें, पर पहले फ़ायरवॉल में नया पोर्ट खोलें (अगला भाग) और लॉगिन जाँचें, वरना अपनी ही पहुँच बंद कर लेंगे।
06. बेसिक फ़ायरवॉल और स्वचालित सुरक्षा
फ़ायरवॉल से हर ग़ैर-ज़रूरी चीज़ बंद करें और fail2ban चालू करें (यह SSH पर पासवर्ड ब्रूट-फ़ोर्स को बैन करता है)। पहले SSH की अनुमति दें, वरना UFW चालू करते ही एक्सेस खो देंगे।
# SSH (या अपना पोर्ट, अगर बदला हो) और वेब की अनुमति दें:
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
# फ़ायरवॉल चालू करें:
sudo ufw enable
sudo ufw status verbose
# fail2ban — ब्रूट-फ़ोर्स से SSH की सुरक्षा (बेसिक प्रोफ़ाइल तुरंत सक्रिय):
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
यह न्यूनतम है। fail2ban की वर्किंग सेटिंग्स, ipsum ब्लॉक-लिस्ट, विस्तारित UFW और बाकी टूल — संदर्भिका के “सुरक्षा टूल” समूह में हैं। Arcivéo Monitor पैनल स्वयं इन सबकी स्थिति स्पष्ट रूप से दिखाएगा।
07. HestiaCP पैनल की स्थापना (वैकल्पिक)
HestiaCP — मुफ़्त होस्टिंग नियंत्रण पैनल: यह वेब-सर्वर (nginx + apache), PHP, डेटाबेस (MariaDB), मेल, DNS और SSL-प्रमाणपत्र इंस्टॉल व कॉन्फ़िगर करता है और साइटों के लिए वेब-इंटरफ़ेस देता है। यदि आप सब कुछ मैन्युअल रूप से सेट नहीं करना चाहते और साइटें (सहित Arcivéo Monitor पैनल भी) होस्ट करने की योजना है, तो यह सुविधाजनक है।
HestiaCP को साफ़ सर्वर पर इंस्टॉल करें (ताज़ा समर्थित Ubuntu/Debian, न्यूनतम ~1–2 GB RAM), अन्य वेब-सर्वर व DB इंस्टॉल करने से पहले — वरना टकराव होंगे। इंस्टॉलेशन में 10–20 मिनट लगते हैं और सर्वर रीबूट होगा।
इंस्टॉलर email और होस्ट-नाम पूछेगा, फिर पूरा स्टैक इंस्टॉल करेगा। रीबूट के बाद पैनल https://YOUR_IP:8083 पते पर उपलब्ध होगा (लॉगिन और पासवर्ड इंस्टॉलर अंत में दिखाएगा)।
HestiaCP ख़ुद UFW और fail2ban का प्रबंधन करता है — इन्हें अलग से कॉन्फ़िगर करने की ज़रूरत नहीं, यह अपने-आप पकड़ लेगा। SSH-कुंजियाँ और पासवर्ड बंद करना (पिछला भाग) फिर भी कर लें।
08. सिस्टम आवश्यकताएँ और ionCube
पैनल एक PHP एप्लिकेशन है जो सामान्य LAMP/LEMP स्टैक पर चलता है:
OS: Linux (Ubuntu/Debian अनुशंसित);
वेब सर्वर: nginx या Apache के साथ PHP-FPM;
PHP 8.0+ इन एक्सटेंशन के साथ: pdo_mysql, openssl, curl, json, mbstring;
ionCube Loader — पैनल के काम करने के लिए आवश्यक PHP एक्सटेंशन;
DB: MySQL 5.7+ या MariaDB 10.3+;
HTTPS — अनिवार्य (लॉगिन और WebAuthn केवल https पर काम करते हैं);
वेब सर्वर उपयोगकर्ता के लिए sudo (सीमित सेट — चरण 13).
# PHP संस्करण और एक्सटेंशन जाँचें:
php -v
php -m | grep -iE 'pdo_mysql|openssl|curl|mbstring|ioncube'
ionCube Loader इंस्टॉल करना (यदि अभी तक नहीं है)। पैनल वाली होस्टिंग (HestiaCP, cPanel) पर ionCube को PHP सेटिंग्स में चेकबॉक्स से चालू किया जाता है। Ubuntu/Debian पर मैन्युअल रूप से:
# PHP संस्करण और एक्सटेंशन डायरेक्टरी जानें:
php -v
EXTDIR=$(php -r 'echo ini_get("extension_dir");'); PHPVER=$(php -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;')
# लोडर डाउनलोड और अनपैक करें (64-bit):
cd /tmp
wget -q https://downloads.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz
tar xzf ioncube_loaders_lin_x86-64.tar.gz
# अपने PHP संस्करण के अनुरूप लोडर को एक्सटेंशन डायरेक्टरी में कॉपी करें:
sudo cp ioncube/ioncube_loader_lin_${PHPVER}.so "$EXTDIR"/
# जोड़ें (CLI + PHP-FPM) और पुनः आरंभ करें:
echo "zend_extension=ioncube_loader_lin_${PHPVER}.so" | sudo tee /etc/php/${PHPVER}/mods-available/ioncube.ini
sudo phpenmod ioncube
sudo systemctl restart php${PHPVER}-fpm
# जाँच — आउटपुट में "with the ionCube PHP Loader" पंक्ति दिखेगी:
php -v
लोडर का संस्करण PHP संस्करण से मेल खाना चाहिए (उदाहरण के लिए PHP 8.1 के लिए ioncube_loader_lin_8.1.so)। यदि आप कई PHP संस्करण उपयोग करते हैं — तो प्रत्येक के लिए लोडर जोड़ें।
09. डोमेन और DNS
पैनल को monitor.example.com जैसे पते पर खोलने और मुफ्त SSL पाने के लिए — एक ऐसा डोमेन चाहिए जो आपके सर्वर की ओर इशारा करता हो। DNS प्रबंधन पैनल में एक A-रिकॉर्ड बनाएँ:
प्रकार: A
नाम: monitor (सबडोमेन → monitor.example.com)
या @ (डोमेन रूट → example.com)
मान: 203.0.113.10 ← आपके सर्वर का IP
TTL: 3600
कुछ मिनट बाद जाँचें कि डोमेन सर्वर की ओर इशारा कर रहा है:
dig +short monitor.example.com # आपका IP लौटाना चाहिए
# या, अगर dig न हो:
getent hosts monitor.example.com
Let's Encrypt SSL-प्रमाणपत्र केवल डोमेन पर ही जारी होता है — प्रमाणपत्र जारी होने से पहले DNS को सर्वर की ओर इशारा करना चाहिए।
10. साइट बनाएँ और पैनल फ़ाइलें अपलोड करें
Apache: DocumentRoot — पैनल के रूट पर, public/ पर नहीं। स्टाइल (CSS/JS), sw.js, manifest.jsonpublic/ के साथ assets/ में रहते हैं और साइट के रूट से माँगे जाते हैं। रूट .htaccess — फ्रंट-कंट्रोलर है। अगर Apache में DocumentRoot public/ पर सेट किया — तो पैनल बिना स्टाइल के खुलेगा। शुद्ध nginx के लिए — उल्टा: रूट के रूप में public/ लिया जाता है, और assets/ एक अलग नियम से दिए जाते हैं (नीचे nginx ब्लॉक देखें)।
पैनल फ़ाइलें (डिस्ट्रिब्यूशन आर्काइव) खरीद के बाद अकाउंट my.arciveo.com → “डाउनलोड” में डाउनलोड होती हैं। अपलोड करने से पहले आर्काइव अनपैक करें।
1) पैनल डायरेक्टरी बनाएँ और उसमें डिस्ट्रिब्यूशन की सामग्री अपलोड करें (ताकि अंदर public/, assets/, config.php आदि आ जाएँ):
sudo mkdir -p /var/www/monitor
# फिर डिस्ट्रिब्यूशन फ़ाइलें /var/www/monitor में अपलोड करें (FileZilla / WinSCP / scp)
2) वेब-सर्वर कॉन्फ़िगर करें।Apache: DocumentRoot — पैनल के रूट पर (/public पर नहीं); AllowOverride All अनिवार्य है। PHP-FPM सॉकेट का पथ अपने आप पता चल जाता है। ब्लॉक टर्मिनल में पूरा पेस्ट किया जाता है:
PHPSOCK=$(ls -1 /run/php/php*-fpm.sock 2>/dev/null | head -1) # PHP-FPM सॉकेट का स्वतः पता लगाना
sudo tee /etc/apache2/sites-available/monitor.conf > /dev/null <<'EOF'
<VirtualHost *:80>
ServerName monitor.example.com
DocumentRoot /var/www/monitor
<Directory /var/www/monitor>
AllowOverride All
Require all granted
</Directory>
<FilesMatch \.php$>
SetHandler "proxy:unix:__PHPSOCK__|fcgi://localhost"
</FilesMatch>
</VirtualHost>
EOF
sudo sed -i "s#__PHPSOCK__#${PHPSOCK}#" /etc/apache2/sites-available/monitor.conf
sudo a2dissite 000-default.conf
sudo a2ensite monitor.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
nginx: nginx में .htaccess नहीं होता, इसलिए रूट के रूप में public/ लेते हैं, और assets/, sw.js, manifest.json (एक स्तर ऊपर) एक अलग नियम से देते हैं:
PHPSOCK=$(ls -1 /run/php/php*-fpm.sock 2>/dev/null | head -1) # PHP-FPM सॉकेट का स्वतः पता लगाना
sudo tee /etc/nginx/sites-available/monitor.conf > /dev/null <<'EOF'
server {
listen 80;
server_name monitor.example.com;
root /var/www/monitor/public;
index index.php;
# assets, service worker और manifest public/ से एक स्तर ऊपर रहते हैं
location ~ ^/(assets/|sw\.js|manifest\.json) { root /var/www/monitor; }
location / { try_files $uri $uri/ /index.php?$query_string; }
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:__PHPSOCK__;
}
}
EOF
sudo sed -i "s#__PHPSOCK__#${PHPSOCK}#" /etc/nginx/sites-available/monitor.conf
sudo ln -s /etc/nginx/sites-available/monitor.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
फ़ाइल अपलोड — SFTP/SCP (FileZilla, WinSCP) या scp:
# लोकल कंप्यूटर से scp के ज़रिए उदाहरण:
scp -r ./monitor/* deploy@203.0.113.10:/var/www/monitor/
फ़ाइलों पर अनुमतियाँ सेट करें — यह अनिवार्य चरण है। अगर root के तहत या SFTP से अपलोड किया, तो फ़ाइलें root की होती हैं, और वेब-सर्वर (www-data) उन्हें पढ़ नहीं पाएगा — पैनल खाली या 403 त्रुटि के साथ खुलेगा (लॉग में: .htaccess unreadable / directory not executable)। नीचे दी कमांड इसे ठीक करती है:
# पूरे वेबरूट की अनुमतियाँ सामान्य करते हैं: root द्वारा बनाई डायरेक्टरी
# वेब-सर्वर (www-data) के लिए अगम्य होती है — इसके बिना पैनल खाली पेज या 403 देता है।
# Apache www-data के तहत चलता है; अगर आपका वेब-यूज़र अलग है — तो बदल दें।
cd /var/www/monitor
# काम की फ़ोल्डर chown से पहले बनाएँ — वरना नई डायरेक्टरियाँ root:root रहेंगी
# और chmod 750 पर वेब-सर्वर (www-data) उनमें लिख नहीं पाएगा।
sudo mkdir -p data/lynis data/logwatch tmp logs
sudo chown -R www-data:www-data /var/www/monitor
sudo find /var/www/monitor -type d -exec chmod 755 {} \;
sudo find /var/www/monitor -type f -exec chmod 644 {} \;
sudo chmod 640 /var/www/monitor/config.php
sudo chmod 750 data tmp logs
3) अपने लिए SFTP से फ़ाइल अपलोड खोलें। ऊपर वाली कमांड के बाद सभी फ़ाइलें www-data की हो जाती हैं, जबकि FileZilla / WinSCP आपके अपने यूज़र से जुड़ते हैं — तब अपलोड SSH_FX_PERMISSION_DENIED (Permission denied) के साथ विफल होगा। अपलोड के लिए root से लॉगिन करना भी संभव नहीं — root लॉगिन स्टेप 05 में बंद कर दिया गया था। दो विकल्पों में से एक चुनें।
विकल्प A — केवल आपके यूज़र के लिए ACL (अनुशंसित)। लिखने का अधिकार सिर्फ़ आपको मिलता है; वेब-सर्वर तब भी पैनल का कोड नहीं बदल सकता:
sudo apt install -y acl
# पैनल की पूरी डायरेक्टरी पर आपके यूज़र को लिखने का अधिकार:
sudo setfacl -R -m u:deploy:rwX /var/www/monitor
# वही नियम डिफ़ॉल्ट के रूप में — बाद में बनने वाली फ़ाइलों और फ़ोल्डरों के लिए:
sudo setfacl -R -d -m u:deploy:rwX /var/www/monitor
विकल्प B — www-data ग्रुप के ज़रिये। आसान है, लेकिन पैनल की फ़ाइलों पर लिखने का अधिकार वेब-सर्वर को भी मिल जाता है: PHP में कोई कमज़ोरी हुई तो कोड बदला जा सकता है। कमांड का क्रम मायने रखता है — config.php और वर्किंग फ़ोल्डर सबसे आख़िर में बंद किए जाते हैं:
sudo usermod -aG www-data deploy
# ग्रुप को लिखने का अधिकार + setgid (बिट 2): SFTP से अपलोड की गई फ़ाइलें
# www-data ग्रुप में ही रहती हैं — वरना पैनल उन्हें दोबारा नहीं लिख सकेगा।
sudo find /var/www/monitor -type d -exec chmod 2775 {} \;
sudo find /var/www/monitor -type f -exec chmod 664 {} \;
sudo chmod 640 /var/www/monitor/config.php
sudo chmod 2750 /var/www/monitor/data /var/www/monitor/tmp /var/www/monitor/logs
विकल्प B के बाद FileZilla में दोबारा कनेक्ट करें (सर्वर → डिस्कनेक्ट, फिर से लॉगिन करें) — नया ग्रुप नए लॉगिन पर ही लागू होता है, उससे पहले अधिकार फिर भी नहीं मिलेंगे। जाँच: id deploy — ग्रुप सूची में www-data दिखना चाहिए; ls -ld /var/www/monitor — अधिकार drwxrwsr-x, x की जगह s अक्षर का मतलब है कि setgid सेट है।
11. डेटाबेस
डेटाबेस और उपयोगकर्ता बनाएँ, फिर स्कीमा इम्पोर्ट करें. यह ब्लॉक टर्मिनल में पूरा पेस्ट करें. monitor_db और monitor_user — उदाहरण के नाम हैं, आप अपनी पसंद के कोई भी रख सकते हैं; डेटाबेस, उपयोगकर्ता और पासवर्ड याद रखें — इन्हें अगले चरण में config.php में लिखेंगे:
# 1. डेटाबेस. पासवर्ड एक ही बार DBPASS में सेट होता है और सभी लाइनों में डाला जाता है.
# यह ब्लॉक टर्मिनल में पूरा पेस्ट करें; sudo mysql unix-सॉकेट से root में लॉगिन करता है
# (root पासवर्ड की ज़रूरत नहीं). इंटरैक्टिव `sudo mysql -u root -p` का
# कॉपी-पेस्ट के साथ उपयोग न करें — पेस्ट करने पर SQL लाइनें पासवर्ड प्रॉम्प्ट में चली जाएँगी और गायब हो जाएँगी.
DBPASS='CHOOSE_A_PASSWORD' # ← केवल यह लाइन बदलें
sudo mysql <<SQL
CREATE DATABASE IF NOT EXISTS monitor_db CHARACTER SET utf8mb4;
CREATE USER IF NOT EXISTS 'monitor_user'@'localhost' IDENTIFIED BY '$DBPASS';
GRANT ALL ON monitor_db.* TO 'monitor_user'@'localhost';
FLUSH PRIVILEGES;
SQL
# जाँच (monitor_db दिखना चाहिए):
mysql -u monitor_user -p"$DBPASS" -e "SHOW DATABASES;"
# यही पासवर्ड config.php → DB_PASS में लिखें.
स्कीमा इम्पोर्ट करने की ज़रूरत नहीं — यदि डेटाबेस खाली है तो ब्राउज़र में पहली बार खुलने पर पैनल स्वयं टेबल और admin अकाउंट बना लेता है (database/db.sql से). स्कीमा का मैन्युअल इम्पोर्ट तभी ज़रूरी है जब ऑटो-इनिशियलाइज़ेशन काम न करे.
यदि आपने ब्राउज़र इंस्टॉलर public/start_db.php का उपयोग किया है — तो इंस्टॉलेशन के तुरंत बाद उसे हटा दें: यह बिना प्रमाणीकरण के डेटाबेस दोबारा बनाने देता है. जब तक यह फ़ाइल पैनल के रूट में या public/ में रहती है, पैनल एक लाल चेतावनी दिखाता है.
12. config.php की सेटिंग
पैनल के रूट में config.php (/var/www/monitor/config.php) — यही एकमात्र फ़ाइल है जिसे हाथ से संपादित करना ज़रूरी है। पैनल की सभी सेटिंग्स इसमें define() स्थिरांकों के रूप में दी गई हैं। इसे एडिटर में खोलें:
sudo nano /var/www/monitor/config.php
हाइलाइट किए गए स्थानों पर अपने मान डालें; बाकी को वैसा ही रहने दें:
// --- डेटाबेस (चरण 11 से) ---
define('DB_HOST', 'localhost'); // वैसा ही रहने दें
define('DB_NAME', 'db_name'); // जो चरण 11 में बनाया
define('DB_USER', 'user'); // जो चरण 11 में बनाया
define('DB_PASS', 'db_password'); // जो चरण 11 में तय किया
define('DB_CHARSET', 'utf8mb4'); // वैसा ही रहने दें
// --- एप्लिकेशन ---
define('APP_URL', 'https://monitor.example.com'); // पैनल का पता, अंत में स्लैश के बिना
define('TIMEZONE', 'Asia/Kolkata'); // आपका टाइम ज़ोन
// --- सेशन का समय ---
define('SESSION_LIFETIME', 28800); // दोबारा लॉगिन तक निष्क्रियता, सेकंड (28800 = 8 घं)
क्या बदलना है:
DB_NAME, DB_USER, DB_PASS — ठीक वही डेटाबेस नाम, यूज़र और पासवर्ड जो आपने चरण 11 में DB बनाते समय तय किए थे (अगर उदाहरण वैसे ही रखे — monitor_db / monitor_user)। DB_HOST और DB_CHARSET को न छुएं।
APP_URL — https:// के साथ पैनल का पूरा पता, अंत में स्लैश के बिना और www के बिना। यह उसी डोमेन से मेल खाना चाहिए जिस पर आप लाइसेंस सक्रिय करते हैं (चरण 16), वरना की अस्वीकार हो जाएगी।
TIMEZONE — आपका टाइम ज़ोन (सूची — timedatectl list-timezones)। यह केवल इस पर असर डालता है कि पैनल तारीखें कैसे दिखाता है; cron कार्यों के चलने के समय पर इसका असर नहीं होता (वहां सिस्टम का ज़ोन लागू होता है)।
SESSION_LIFETIME — कितने सेकंड की निष्क्रियता के बाद पैनल दोबारा लॉगिन के लिए कहेगा (डिफ़ॉल्ट 8 घंटे)। जैसे 3600 = 1 घंटा, 86400 = एक दिन।
फ़ाइल सहेजें (Ctrl+O, Enter, फिर Ctrl+X) और PHP-FPM को रीस्टार्ट करें — वरना OPcache के कारण बदलाव लागू नहीं होंगे:
sudo systemctl restart php*-fpm
config.php — गोपनीय फ़ाइल है (इसमें DB पासवर्ड है)। यह पैनल के रूट में है, जो वेब-रूट भी है, पर यह सुरक्षित है: अनुमतियाँ 640 (चरण 10 में सेट) और रूट .htaccess में स्पष्ट प्रतिबंध। इसे सार्वजनिक रिपॉज़िटरी में न डालें और असली पासवर्ड के साथ सपोर्ट को न भेजें।
PHP वेब-सर्वर के उपयोगकर्ता के रूप में चलता है, जिसके पास सिस्टम कमांड चलाने के अधिकार नहीं होते। पहुँच सीमित रूप से दी जाती है: विशिष्ट उपयोगिताओं पर सटीक sudo और ग्रुप के ज़रिये लॉग पढ़ना (बिना sudo)। वेब-लेयर हैक होने पर भी root नहीं मिलता।
उदाहरणों में www-data Apache का मानक उपयोगकर्ता है। अगर आपका उपयोगकर्ता अलग है (कुछ पैनल में PHP अलग उपयोगकर्ता के अंतर्गत चलता है) — तो हर जगह उसे बदलें। जानने के लिए: ps -o user= -C php-fpm | sort -u.
1.sudo visudo -f /etc/sudoers.d/monitor के ज़रिये /etc/sudoers.d/monitor बनाएँ और यह डालें (जिन मॉड्यूल का उपयोग नहीं करते उनकी पंक्तियाँ हटा दें):
# UFW — स्थिति और नियम (“फ़ायरवॉल” पेज)
www-data ALL=(ALL) NOPASSWD: /usr/sbin/ufw status, /usr/sbin/ufw status verbose, /usr/sbin/ufw status numbered
www-data ALL=(ALL) NOPASSWD: /usr/sbin/ufw allow [0-9]*, /usr/sbin/ufw deny [0-9]*, /usr/sbin/ufw --force delete [0-9]*
# Fail2ban — स्थिति, बैन और अनबैन (banned एक ही कमांड से सभी jail के बैन देता है;
# ban/unban पैनल के बटनों के लिए ज़रूरी हैं)
www-data ALL=(ALL) NOPASSWD: /usr/bin/fail2ban-client status, /usr/bin/fail2ban-client status *, /usr/bin/fail2ban-client banned, /usr/bin/fail2ban-client set * banip *, /usr/bin/fail2ban-client set * unbanip *
# सुरक्षा अपडेट (“अपडेट” कार्ड)। केवल पढ़ना, पर root से ही:
# apt कैश (~70 MB) केवल root को उपलब्ध है, non-root हर कॉल पर उसे फिर से बनाता है
# (4.2 सेकंड CPU बनाम 0.01 सेकंड)। बिना wildcard — बस यही एक कमांड, कुछ इंस्टॉल नहीं करती।
www-data ALL=(ALL) NOPASSWD: /usr/bin/apt list --upgradable
# IPset (अटैक मानचित्र, डैशबोर्ड)
www-data ALL=(ALL) NOPASSWD: /usr/sbin/ipset list -t ipsum
# CrowdSec
www-data ALL=(ALL) NOPASSWD: /usr/bin/cscli decisions list *, /usr/bin/cscli alerts list *, /usr/bin/cscli bouncers list *, /usr/bin/cscli scenarios list *
# Auditd — घटनाओं की खोज + जर्नल की अंतिम पंक्तियाँ पढ़ना (सटीक पथ)
www-data ALL=(ALL) NOPASSWD: /usr/sbin/ausearch -m *
www-data ALL=(ALL) NOPASSWD: /usr/bin/tail -n 300 /var/log/audit/audit.log
# Monit / ModSecurity / AppArmor / PSAD
www-data ALL=(ALL) NOPASSWD: /usr/bin/monit status
www-data ALL=(ALL) NOPASSWD: /usr/sbin/apache2ctl -M
www-data ALL=(ALL) NOPASSWD: /usr/local/bin/monitor-modsec
www-data ALL=(ALL) NOPASSWD: /usr/sbin/aa-status
www-data ALL=(ALL) NOPASSWD: /usr/sbin/psad --Status
# खुले पोर्ट (कर्नेल/SSH/Falco के लॉग बिना sudo पढ़े जाते हैं — systemd-journal
# ग्रुप के ज़रिये, देखें बिंदु 2; journalctl के लिए sudo देना ज़रूरी नहीं और असुरक्षित है)
www-data ALL=(ALL) NOPASSWD: /usr/bin/ss -tuln, /usr/sbin/ss -tuln, /bin/ss -tuln
# PostgreSQL (केवल अगर उपयोग करते हैं) — निश्चित read-only स्क्रिप्ट,
# FAQ “PostgreSQL दिखाई नहीं देता” के अनुसार बनाएँ; उसके बिना इस पंक्ति को हटा दें
www-data ALL=(ALL) NOPASSWD: /usr/local/bin/monitor-pgstat
2. लॉग और systemd जर्नल तक पहुँच। मॉड्यूल /var/log/fail2ban.log, auth.log, ufw.log, apache2/*, aide को सीधे पढ़ते हैं (Debian/Ubuntu पर ये लॉग adm ग्रुप में होते हैं)। कर्नेल, SSH और Falco की घटनाएँ journald से journalctl कमांड द्वारा बिना sudo, systemd-journal ग्रुप के ज़रिये ली जाती हैं। वेब-उपयोगकर्ता को दोनों ग्रुप में जोड़ें और PHP-FPM पुनः आरंभ करें:
sudo usermod -aG adm,systemd-journal www-data
sudo systemctl restart php*-fpm # अनिवार्य, वरना ग्रुप लागू नहीं होंगे
3. अगर ClamAV या Suricata अपने लॉग adm ग्रुप में नहीं लिखते (कभी-कभी root:root होता है) — तो ACL के ज़रिये पहुँच दें:
4. ModSecurity रैपर। WAF का ऑडिट-लॉग (/var/log/apache2/modsec_audit.log) root का है और उसकी अनुमतियाँ 640 हैं, इसलिए वेब-उपयोगकर्ता उसे सीधे नहीं पढ़ सकता। ModSecurity पेज इंजन मोड, घटनाएँ और सक्रिय नियमों की सूची एक निश्चित read-only स्क्रिप्ट के ज़रिये लेता है — जिसकी अनुमति ऊपर की sudoers पंक्ति में दी गई है:
/etc/modsecurity/modsecurity.conf फ़ाइल के बिना WAF स्वयं काम नहीं करता: पैकेज केवल modsecurity.conf-recommended रखता है, और नियम-इंजन बंद ही रहता है — इसे कैसे चालू करें, देखें FAQ → “ModSecurity की स्थापना”.
sudoers की सभी पंक्तियों में उपयोगकर्ता FPM-पूल के उपयोगकर्ता से मेल खाना चाहिए: सामान्य Apache/Debian पर यह www-data है, HestiaCP में साइट का पूल साइट के मालिक (उदाहरण के लिए admin) के रूप में चलता है — जाँचें grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf.
5. अगर Apache के आगे Nginx है (HestiaCP, ISPmanager और अन्य पैनल — वहाँ Nginx PHP को Apache में प्रॉक्सी करता है, और स्टैटिक स्वयं देता है)। सेवा-निर्देशिकाएँ .htaccess फ़ाइलों से बंद हैं, पर Nginx उन्हें नहीं पढ़ता: कोई भी स्टैटिक फ़ाइल (.json, .txt, .log, .dat) वह Apache को दरकिनार करके सीधे दे देगा। बाहर पैनल के कैश और डेटा लीक होंगे — उदाहरण के लिए WAF की घटनाओं और हमलावरों के IP वाला tmp/modsec_cache.json। Nginx साइट कॉन्फ़िग में रोक जोड़ें:
^~ प्रिफ़िक्स अनिवार्य है: वह location / के भीतर स्टैटिक के लिए रेगुलर नियम से पहले चुना जाता है, वरना रोक काम नहीं करेगी।
HestiaCP में इसे अलग फ़ाइल /home/<user>/conf/web/<domain>/nginx.ssl.conf_deny (और HTTP के लिए nginx.conf_deny) के रूप में रखें — साइट कॉन्फ़िग nginx.ssl.conf_* को जोड़ता है और पुनर्निर्माण के समय ऐसी फ़ाइलों को नहीं मिटाता। लागू करें: sudo nginx -t && sudo systemctl reload nginx.
जाँच: curl -s -o /dev/null -w '%{http_code}\n' https://monitor.example.com/tmp/modsec_cache.json — 403 होना चाहिए। अगर Apache Nginx के बिना चलता है (स्वयं 80/443 सुनता है), तो कुछ जोड़ने की ज़रूरत नहीं — .htaccess पर्याप्त है।
बाइनरी के पथ which से जाँचें (उदाहरण के लिए which ufw cscli ausearch ss)। sudoers को केवल visudo के ज़रिये ही संपादित करें। सभी MySQL डेटाबेस की सूची अलग GRANT से चालू होती है (FAQ → “केवल एक DB दिखता है”).
14. IP द्वारा एक्सेस प्रतिबंधित करें
मॉनिटर तक एक्सेस को IP पते द्वारा सीमित करें — भले ही URL पता चल जाए, लॉगिन पेज नहीं खुलेगा। यह वेब सर्वर स्तर पर (nginx के लिए उदाहरण नीचे) या पैनल में ही किया जा सकता है (“सेटिंग्स” → “IP द्वारा एक्सेस प्रतिबंध”)। अगर आपके पास Apache है, तो पैनल के प्रतिबंध का उपयोग करें।
अगर nginx साइट पहले से चरण 10 के अनुसार सेट है, तो दूसरा न जोड़ेंlocation / — allow/deny लाइनें पहले से मौजूद ब्लॉक में लिखें। एक ही server { } में दो एक जैसे location / — कॉन्फ़िगरेशन त्रुटि है, nginx पुनः आरंभ नहीं होगा।
# nginx कॉन्फ़िग में (server { } के अंदर):
# Let's Encrypt का ACME-पथ IP-प्रतिबंध से बचाकर खुला रखें —
# ताकि SSL का जारी होना और ऑटो-नवीनीकरण (चरण 15) IP-फ़िल्टर पर निर्भर न रहे।
location ^~ /.well-known/acme-challenge/ { allow all; }
location / {
allow 203.0.113.10; # ← अपना IP लिखें
allow 10.0.0.0/8; # लोकल नेटवर्क (अगर ज़रूरी हो)
deny all;
try_files $uri $uri/ /index.php?$query_string;
}
# nginx पुनः लोड करें:
sudo nginx -t && sudo systemctl reload nginx
15. SSL (HTTPS) जारी करें
डैशबोर्ड केवल HTTPS पर काम करता है। लॉगिन सेशन एक सुरक्षित cookie का उपयोग करता है, और WebAuthn (2FA) केवल HTTPS पर काम करता है। http:// से लॉगिन संभव नहीं है।
सर्टिफिकेट मुफ़्त है (Let's Encrypt)। डोमेन का DNS पहले से ही सर्वर की ओर इशारा करता होना चाहिए। कमांड वेब-सर्वर पर निर्भर करती है:
# Apache:
sudo certbot --apache -d monitor.example.com
# nginx — केवल तभी जब आपके पास वास्तव में nginx हो। Apache पर न चलाएँ:
# apt nginx को खींच लेगा और पोर्ट 80 पर कब्ज़ा कर लेगा, Apache से टकराव होगा।
# sudo apt install python3-certbot-nginx
# sudo certbot --nginx -d monitor.example.com
# certbot खुद HTTPS को कॉन्फ़िग में लिख देगा और ऑटो-रिन्यूअल सेट कर देगा
certbot क्या पूछेगा: e-mail → Terms से सहमति (Y) → EFF को e-mail भेजना (आपकी मर्ज़ी)। फिर वह खुद सर्टिफिकेट जारी करेगा, <VirtualHost *:443> लिखेगा, http→https रीडायरेक्ट और ऑटो-रिन्यूअल सेट करेगा।
certbot चलाने से पहले DNS सर्वर की ओर इशारा करता होना चाहिए (पोर्ट 80 के ज़रिए स्वामित्व जाँच)। जाँच: dig +short monitor.example.com → सर्वर का IP। पोर्ट 80/443 खुले हों: sudo ufw allow 80,443/tcp।
जारी होने के बाद: https://monitor.example.com ताले के साथ खुलता है, http://https:// पर रीडायरेक्ट करता है (config.php में APP_URL चरण 12 में पहले ही सेट हो चुका है)।
16. लॉग-इन और प्रारंभिक सेटअप
https://monitor.example.com खोलें, admin / useradmin से लॉग-इन करें और चेकलिस्ट पूरी करें:
admin पासवर्ड बदलें — मेनू में “उपयोगकर्ता” अनुभाग।
WebAuthn (2FA) चालू करें — “WebAuthn कुंजियाँ” → कुंजी/passkey पंजीकृत करें (HTTPS आवश्यक)। एक साथ दो पंजीकृत करें: एकमात्र कुंजी खो जाने पर उससे लॉग-इन संभव नहीं होगा। अधिक जानकारी।
IP द्वारा पहुँच सीमित करें — “सेटिंग्स” → “IP द्वारा पहुँच प्रतिबंध” (चालू करने से पहले अपना IP दर्ज करें, अन्यथा आप स्वयं की पहुँच बंद कर देंगे)।
लाइसेंस दर्ज करें — अकाउंट से ARCIVEO-… कोड को अपने डोमेन पर सक्रिय करें और कुंजी को “सेटिंग्स” → “लाइसेंस” में डालें। अधिक जानकारी।
सूचनाएँ कॉन्फ़िगर करें — “सेटिंग्स” में Telegram और/या Email। अधिक जानकारी।
इंस्टॉलर हटाएँpublic/start_db.php, यदि वह बचा हो (चरण 11)।
17. सुरक्षा उपकरण (वैकल्पिक)
डैशबोर्ड पहले से चालू है। उपकरण इच्छानुसार लगाए जाते हैं — जो चाहिए वही लगाएँ, डैशबोर्ड तुरंत स्थिति दिखा देगा। हर एक की इंस्टॉलेशन कमांड्स संदर्भ में हैं (उपकरणों के अलग-अलग खंड):