مکمل دستی تنصیب: ابھی خریدے گئے VPS سے لے کر چلتے ہوئے ڈیش بورڈ تک، مرحلہ وار۔
سرور کی تیاری، سائٹ بنانا، ڈیٹابیس، config.php اور SSL یہاں تفصیل سے بیان ہیں۔
ہر سیکیورٹی ٹول اور cron کے کمانڈز
FAQ-حوالہ جات میں ہیں، لنکس دورانِ عمل دیے گئے ہیں۔
بنیادی اصول: SSH یا فائر وال تبدیل کرتے وقت، جب تک نئے کنکشن کو الگ ونڈو میں جانچ نہ لیں، موجودہ کنکشن بند نہ کریں۔ اگر پھر بھی رسائی ختم ہو جائے — تقریباً تمام ہوسٹنگ فراہم کنندگان اپنے کنٹرول پینل میں ایمرجنسی کنسول (VNC/Recovery) دیتے ہیں۔
01. Ubuntu/Debian والا VPS خریدا — کہاں سے شروع کریں
خریداری کے بعد ہوسٹنگ فراہم کنندہ بھیجتا ہے: IP ایڈریس، صارف نام (عام طور پر root) اور پاس ورڈ (یا SSH کلید)۔ لاگ اِن کے لیے یہ کافی ہے۔ اقدامات کی ترتیب (ہر مرحلہ نیچے ایک سیکشن ہے):
SSH کے ذریعے سرور سے منسلک ہوں؛
سسٹم اپ ڈیٹ کریں، ہوسٹ نام اور ٹائم زون سیٹ کریں؛
sudo حقوق کے ساتھ ایک عام صارف بنائیں (root کے تحت کام نہ کریں)؛
SSH کلید سے لاگ اِن سیٹ کریں اور پاس ورڈ سے لاگ اِن بند کریں؛
فائر وال اور خودکار تحفظ فعال کریں؛
(اختیاری) کنٹرول پینل HestiaCP انسٹال کریں — ویب سرور، ڈیٹابیس، ای میل “باکس سے باہر”۔
02. SSH کے ذریعے پہلا کنکشن
SSH سرور تک ایک محفوظ ٹرمینل ہے۔ 203.0.113.10 کی جگہ اپنا IP لکھیں۔
203.0.113.10 ایک مثال ہے، غیر موجود پتہ (دستاویزات کے لیے مختص)۔ اسے ویسے ہی درج نہ کریں — اسے ہوسٹر کے خط میں دیے گئے اپنے سرور کے اصل IP سے بدل دیں۔ ورنہ کنکشن نہیں بنے گا۔
Windows 10/11: PowerShell یا “ٹرمینل” کھولیں اور بلٹ اِن ssh استعمال کریں (یا PuTTY / MobaXterm کلائنٹس)۔ macOS / Linux: “ٹرمینل” کھولیں۔
# root کے طور پر لاگ اِن (پاس ورڈ ہوسٹر کی طرف سے آیا ہے):
ssh root@203.0.113.10
# اگر ہوسٹر نے پاس ورڈ کے بجائے کلید-فائل دی ہو:
ssh -i راستہ/کلید/تک 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)، دیگر ویب سرورز اور ڈیٹابیس نصب کرنے سے پہلے — ورنہ تصادم ہوں گے۔ تنصیب میں 10–20 منٹ لگتے ہیں اور سرور ری بوٹ ہو جائے گا۔
# انسٹالر ڈاؤن لوڈ کر کے چلائیں:
wget https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh
sudo bash hst-install.sh
انسٹالر email اور ہوسٹ نام پوچھے گا، پھر پورا اسٹیک نصب کرے گا۔ ری بوٹ کے بعد پینل https://YOUR_IP:8083 پر دستیاب ہوگا (لاگ اِن اور پاس ورڈ انسٹالر آخر میں دکھائے گا)۔
HestiaCP UFW اور fail2ban کو خود منظم کرتا ہے — انہیں الگ سے ترتیب دینے کی ضرورت نہیں، یہ خود سنبھال لے گا۔ SSH کیز اور پاس ورڈ غیر فعال کرنا (پچھلا سیکشن) پھر بھی ضرور کریں۔
08. سسٹم تقاضے اور ionCube
پینل — عام LAMP/LEMP اسٹیک پر مبنی ایک PHP ایپلیکیشن ہے:
OS: Linux (Ubuntu/Debian تجویز کردہ)؛
ویب سرور: nginx یا Apache بمع PHP-FPM؛
PHP 8.0+ ان ایکسٹینشنز کے ساتھ: pdo_mysql, openssl, curl, json, mbstring؛
ionCube Loader — ایک PHP ایکسٹینشن جو پینل کے کام کے لیے ضروری ہے؛
ڈیٹابیس: MySQL 5.7+ یا MariaDB 10.3+؛
HTTPS — لازمی (لاگ اِن اور WebAuthn صرف https پر کام کرتے ہیں)؛
ویب سرور کے صارف کے لیے sudo (محدود سیٹ — مرحلہ 13)۔
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
۳) اپنے لیے SFTP سے فائل اپلوڈ کھولیں۔ اوپر والی کمانڈ کے بعد تمام فائلیں www-data کی ملکیت ہوتی ہیں، جبکہ FileZilla / WinSCP آپ کے اپنے صارف سے جڑتے ہیں — تب اپلوڈ SSH_FX_PERMISSION_DENIED (Permission denied) کے ساتھ ناکام ہوگا۔ اپلوڈ کے لیے root سے لاگ اِن کرنا بھی ممکن نہیں — root لاگ اِن مرحلہ ۰۵ میں بند کر دیا گیا تھا۔ دو میں سے ایک طریقہ منتخب کریں۔
طریقہ 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 یونکس ساکٹ سے 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 میں درج کریں۔
اسکیما درآمد کرنے کی ضرورت نہیں — اگر ڈیٹابیس خالی ہو تو پینل خود براؤزر میں پہلی بار داخلے پر (database/db.sql سے) ٹیبلز اور admin اکاؤنٹ بنا لیتا ہے۔ اسکیما کی دستی درآمد صرف اُس وقت درکار ہے جب خودکار انیشیئلائزیشن نہ چلے۔
اگر آپ نے براؤزر انسٹالر 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/Karachi'); // آپ کا ٹائم زون
// --- سیشن کا دورانیہ ---
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 = ایک دن۔
خرابیوں کی لاگنگ کا حصہ (display_errors، log_errors، error_log) — طے شدہ حالت میں رہنے دیں۔
فائل محفوظ کریں (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 کو دستیاب ہے، غیر-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 دوبارہ شروع کریں:
4. ModSecurity ریپر۔ WAF کا آڈٹ لاگ (/var/log/apache2/modsec_audit.log) 640 حقوق کے ساتھ root کا ہے، ویب صارف اسے براہ راست نہیں پڑھ سکتا۔ 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 کو نظرانداز کر کے دے دے گا۔ باہر پینل کے کیش اور ڈیٹا لیک ہو جائیں گے — مثلاً tmp/modsec_cache.json جس میں WAF واقعات اور حملہ آوروں کے IP ہیں۔ 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) ← e-mail کو EFF کو دینا (آپ کی صوابدید پر)۔ پھر خود سرٹیفکیٹ جاری کرے گا، <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. سیکیورٹی ٹولز (اختیاری)
پینل پہلے سے کام کر رہا ہے۔ ٹولز آپ کی مرضی سے انسٹال ہوتے ہیں — جو ضرورت ہو وہی لگائیں، پینل فوراً حالت دکھا دے گا۔ ہر ایک کی انسٹالیشن کمانڈز ریفرنس میں ہیں (ٹولز کے الگ الگ سیکشنز):