یہ Arcivéo Monitor کی تنصیب، ترتیب اور دیکھ بھال کی رہنمائی ہے۔ حصے یوں تقسیم ہیں: عمومی جائزہ، پینل کی تعیناتی، سکیورٹی ٹولز کا اتصال، بلٹ اِن ماڈیولز اور تشخیص۔ کمانڈز کو دائیں جانب موجود بٹن سے کاپی کیا جا سکتا ہے۔
پینل کی تنصیب الگ الگ مرحلہ وار صفحات پر ہے۔ طریقہ منتخب کریں:
Arcivéo Monitor — سرور سیکیورٹی ڈیش بورڈ۔ نصب شدہ ٹولز (Fail2ban، UFW، Lynis، ModSecurity، AIDE، ClamAV، Auditd، CrowdSec، Suricata، Falco وغیرہ) سے ڈیٹا اکٹھا کرتا ہے اور اسے ایک ہی انٹرفیس میں ڈیش بورڈ، حملوں کے نقشے اور ہر ٹول کے تفصیلی صفحات کے ساتھ دکھاتا ہے۔
Monitor کوئی فعال تحفظ کا ذریعہ نہیں ہے — یہ خود سے حملوں کو بلاک نہیں کرتا۔ اس کا کام پہلے سے کام کرنے والے ٹولز کی معلومات کو یکجا کرنا اور اسے آسان انداز میں پیش کرنا ہے۔
مانیٹر صرف مقامی طور پر کام کرتا ہے — اسے اسی سرور پر انسٹال کرنا چاہیے جس کی وہ نگرانی کرتا ہے۔ کوئی SSH یا ریموٹ API نہیں ہے۔
تمام کمانڈز (fail2ban-client، ufw status، ipset list وغیرہ) پینل ویب سرور کے صارف (عام طور پر www-data، ہوسٹنگ پینلز پر — سائٹ کا اکاؤنٹ) کی حیثیت سے sudo کے محدود اختیارات کے سیٹ کے ساتھ چلاتا ہے — صرف مخصوص افادیتوں پر، عمومی root رسائی کے بغیر۔ نتائج کو parse کر کے براؤزر میں دکھایا جاتا ہے۔
اسکور زیادہ سے زیادہ قدر سے شروع ہوتا ہے اور ہر شناخت شدہ مسئلے پر کم ہوتا ہے:
PermitRootLogin yes) — −20نتیجہ: 80+ = محفوظ، 60–79 = توجہ، <60 = خطرے میں۔
WebAuthn — ہارڈویئر کلید کے ذریعے بغیر پاس ورڈ توثیق کا معیار۔ YubiKey، Touch ID، Face ID، Windows Hello، Passkey کی سپورٹ کرتا ہے۔
پاس ورڈ سے لاگ اِن کے بعد سسٹم رجسٹرڈ کلید کے ذریعے تصدیق طلب کرتا ہے۔ پاس ورڈ لیک ہو جانے کے باوجود — فزیکل کلید یا بایومیٹرکس کے بغیر لاگ اِن ممکن نہیں۔
سیٹنگ کے لیے سائیڈ مینو میں WebAuthn کلیدیں کھولیں اور “کلید رجسٹر کریں” پر کلک کریں۔ فوراً دو کلیدیں رجسٹر کریں: اگر واحد کلید کھو جائے یا ٹوٹ جائے تو اس کے ذریعے پینل میں لاگ اِن ممکن نہیں ہوگا۔
ڈیش بورڈ سیکیورٹی رپورٹ Telegram اور ای میل پر بھیج سکتا ہے (بٹن سے اور شیڈول کے مطابق)۔ اس کی ترتیب “ترتیبات” سیکشن میں ہوتی ہے۔
Telegram. بوٹ ٹوکن اور chat id درکار ہیں:
@BotFather کو پیغام بھیجیں ← /newbot ← 123456:ABC... جیسا ٹوکن حاصل کریں۔@userinfobot کو پیغام بھیجیں، یا https://api.telegram.org/bot<TOKEN>/getUpdates کھولیں اور "chat":{"id":...} تلاش کریں۔Email. “ترتیبات” ← Email میں دو طریقوں میں سے انتخاب:
re_...) اور تصدیق شدہ بھیجنے والا ڈومین درج کریں۔رپورٹ کی حالت: “توجہ” یا “ٹھیک”۔ عنوان صرف اُس وقت “توجہ” بنتا ہے جب کوئی حقیقی مسئلہ یا زیرِ التوا کارروائی ہو: ClamAV نے خطرہ پایا، AIDE میں فائلوں کی تبدیلیاں، Falco کے تشویشناک واقعات (پچھلے 24 گھنٹوں میں Emergency/Alert/Critical)، Monit میں گِری ہوئی سروس، ری بوٹ درکار، SSL کی میعاد ختم ہو رہی ہے (≤14 دن) یا سیکیورٹی اپ ڈیٹس زیرِ التوا۔ پس منظر کا شور — بوٹس کی SSH بروٹ فورس، fail2ban سے بین شدہ IP، Suricata کے الرٹس، Lynis کی تنبیہات اور ModSecurity کی پہلے سے روکی گئی درخواستیں — حالت کو نہیں بدلتا، اس لیے رپورٹ میں یہ اعداد بذاتِ خود “توجہ” کا مطلب نہیں رکھتے۔
تفصیلی مانیٹرنگ ماڈیولز (Lynis، UFW، ModSecurity، حملوں کا نقشہ، AIDE، ClamAV وغیرہ) درست لائسنس موجود ہونے پر کھلتے ہیں۔ اس کے بغیر ڈیش بورڈ، سیٹنگز اور اکاؤنٹ کام کرتے ہیں، جبکہ ماڈیولز “لائسنس درکار ہے” کارڈ دکھاتے ہیں۔
اکاؤنٹ میں خریداری کے بعد آپ کے پاس ARCIVEO-XXXX-XXXX-XXXX-XXXX کی طرز کا ایکٹیویشن کوڈ ہوتا ہے۔ اسے اپنے پینل کے ڈومین پر “ایکٹیویٹ” کرنا ہوتا ہے — یہ کوڈ کو ایک دستخط شدہ لائسنس فائل ([license] بلاک) میں بدل دیتا ہے، جسے آپ پینل میں پیسٹ کرتے ہیں۔
ایکٹیویٹ کیسے کریں (3 مراحل):
my.arciveo.com → “لائسنس” / “لائسنس ایکٹیویشن” سیکشن — ARCIVEO-… کوڈ کاپی کریں۔monitor.example.com)۔ ایکٹیویٹ دبائیں — سسٹم اس ڈومین سے منسلک لائسنس فائل بنائے گا اور اسے “کاپی” بٹن والے خانے میں دکھائے گا۔پینل کلید کی کرپٹوگرافک تصدیق کرتا ہے: دستخط، ڈومین سے وابستگی اور مدتِ اعتبار۔
config.php میں APP_URL کونسٹنٹ سے لیں اور صرف ہوسٹ نام درج کریں — https:// اور www پریفکس کے بغیر۔ ایکٹیویشن ایک بار کی ہے: کوڈ درج کردہ ڈومین کے لیے لائسنس بن جاتا ہے اور دوبارہ ایکٹیویٹ نہیں ہوتا — ڈومین میں غلطی ہونے پر کلید آپ کے پینل کے لیے کام نہیں کرے گی اور کوڈ ضائع ہو جائے گا۔ اس لیے ڈومین احتیاط سے درج کریں۔
پینل کے تمام بنیادی پیرامیٹرز جڑ میں موجود ایک ہی فائل config.php (public/ فولڈر کے ساتھ) میں عام define() کنسٹنٹس کے ذریعے متعین ہیں۔ فائل انسٹالیشن کے دوران بنتی ہے؛ اسے ہاتھ سے ترمیم کرنے کی ضرورت شاذ و نادر ہی پڑتی ہے — زیادہ تر ڈومین بدلنے، منتقلی یا کسی دوسری ڈیٹابیس سے جوڑنے کے وقت۔ کسی بھی ترمیم کے بعد PHP-FPM کو دوبارہ شروع کریں (ورنہ OPcache کی وجہ سے تبدیلیاں لاگو نہیں ہوں گی)۔
اپنی اقدار نمایاں جگہوں پر ڈالیں؛ باقی سب جوں کا توں چھوڑ دیں:
ڈیٹابیس۔ MySQL/MariaDB سے کنکشن کی تفصیلات:
DB_HOST — DBMS کا ہوسٹ، تقریباً ہمیشہ localhost؛DB_NAME — پینل کی ڈیٹابیس کا نام؛DB_USER — ڈیٹابیس صارف (صرف اپنی ہی ڈیٹابیس تک رسائی)؛DB_PASS — اس صارف کا پاس ورڈ؛DB_CHARSET — کنکشن کی انکوڈنگ، utf8mb4 رہنے دیں۔ایپلیکیشن۔
APP_URL — پینل کا مکمل پتہ (مثلاً https://monitor.example.com)۔ اسے اُس ڈومین سے مطابقت رکھنی چاہیے جس پر لائسنس فعال کیا گیا ہے — ورنہ کلید مسترد ہو جائے گی (دیکھیں سیکشن “لائسنس”)؛TIMEZONE — PHP کا ٹائم زون: یہ صرف اس پر اثر ڈالتا ہے کہ پینل تاریخ اور وقت کیسے دکھاتا ہے۔ cron کاموں کے چلنے کے وقت پر اثر نہیں ڈالتا — وہاں سسٹم کا ٹائم زون لاگو ہوتا ہے (دیکھیں “تمام cron کام”)۔سیشن کا وقت۔ SESSION_LIFETIME — سیشن کی بے عملی کا ٹائم آؤٹ سیکنڈوں میں (پھسلتا ہوا: سرگرمی پر تازہ ہوتا ہے)۔ طے شدہ طور پر 28800 = 8 گھنٹے؛ اتنے وقت کی بے عملی کے بعد پینل دوبارہ لاگ اِن کرنے کو کہے گا۔ مثلاً 3600 = 1 گھنٹہ، 86400 = ایک دن۔
خرابیوں کی لاگنگ۔ خرابیاں کبھی زائرین کو نہیں دکھائی جاتیں، بلکہ logs/php_errors.log میں لکھی جاتی ہیں — وہ “ایپلیکیشن لاگز” صفحے پر نظر آتی ہیں۔ ان سطروں (display_errors=0، log_errors=1، راستہ error_log) کو عموماً بدلنے کی ضرورت نہیں — ترتیبات براہِ راست فائل میں طے ہیں اور php.ini پر منحصر نہیں۔
public/ کے ساتھ)، اور اس پینل کا ویب روٹ (DocumentRoot) بھی پینل کی جڑ ہی ہے، نہ کہ public/۔ فائل خود بخود “لیک” نہیں ہوتی: جڑ کے .htaccess میں اس کے لیے واضح پابندی موجود ہے (Require all denied) — سرور 403 لوٹاتا ہے۔ اس قاعدے کے بغیر بھی سورس لیک نہ ہوتا: یہ PHP ہے — سرور اسے چلاتا ہے، متن کے طور پر نہیں دیتا۔ احتیاطاً: اسے عوامی ریپازٹریز میں نہ ڈالیں اور اصل پاس ورڈ کے ساتھ سپورٹ کو نہ بھیجیں۔ فائل کے حقوق — 640۔
UFW (Uncomplicated Firewall) — nftables/iptables کا آسان انٹرفیس ہے۔ صراحتاً اجازت یافتہ کے سوا تمام آنے والے پورٹ بند کر دیتا ہے۔ “UFW فائر وال” صفحہ حالت اور قواعد دکھاتا ہے۔
ufw enable سے پہلے SSH کی اجازت لازمی دیں (ufw allow OpenSSH)، ورنہ سرور تک رسائی کھو دیں گے۔
deny قاعدے سے بند کیا گیا پورٹ باہر سے قابلِ رسائی شمار نہیں ہوتا۔
Skipping adding existing rule — یہ کوئی خرابی نہیں۔ UFW اس طرح بتاتا ہے کہ بالکل ایسا ہی قاعدہ پہلے سے موجود ہے، اور اسے دوبارہ شامل نہیں کرتا۔ خودکار ترتیب دوبارہ چلانے پر (یہ idempotent ہے) یہ ایک معمول کا پیغام ہے — کسی ردِعمل کی ضرورت نہیں۔
ناکام لاگ اِن کوششوں کی تعداد حد سے بڑھنے پر خودکار طور پر IP بلاک کر دیتا ہے۔ SSH، nginx، Apache اور دیگر سروسز کے لاگز کا تجزیہ کرتا ہے۔
بنیادی تنصیب اوپر ہے۔ یہاں وہ عملی کنفیگریشن ہے جو درجنوں فعال jail اور ہزاروں بلاکس دیتی ہے: عمومی ترتیبات، کلیدی jail اور ipsum فہرست سے نقصان دہ IP کا خودکار بین۔
فائل /etc/fail2ban/jail.local — عمومی ترتیبات اور اہم ترین jail:
ignoreip میں اپنا IP اور قابلِ اعتماد نیٹ ورکس ضرور درج کریں، ورنہ آپ خود بین ہو سکتے ہیں۔ ترامیم کے بعد: sudo fail2ban-client reload۔
ipsum بلاک لسٹ کی خودکار لوڈنگ — root کرون میں (sudo crontab -e): level 1 (1 لاکھ+ IP) ipsum سیٹ میں لوڈ ہوتی ہے، جسے فائروال پر روکا جاتا ہے (تفصیل “IPset بلاک لسٹ” سیکشن میں):
ipsum ہونا لازمی ہے — اسی کو ڈیش بورڈ پڑھتا ہے (“IPset ipsum” کارڈ)۔ لیولز: levels/1.txt — زیادہ سے زیادہ احاطہ، levels/3.txt — زیادہ درست (3+ ذرائع)۔
“سیکیورٹی مانیٹر” دو زونز میں کیوں بٹا ہے۔ تحفظ دو سطحوں پر کام کرتا ہے، اور ڈیش بورڈ انہیں آپس میں نہیں ملاتا:
sshd، apache-*، nginx-* وغیرہ) اور خطرناک عادی مجرم (jail recidive — وہ جنہیں پہلے کئی بار بین کیا جا چکا)۔ یہ وہ IP ہیں جو واقعی آپ پر حملہ آور ہوئے — یہ حملوں کے نقشے اور “ٹائم لائن” پر ہوتے ہیں۔ipset ipsum، جسے فائروال پر DROP قاعدے سے روکا جاتا ہے۔ یہ پتے اکثر آپ کے سرور کو چھوتے بھی نہیں — انہیں پہلے سے روک دیا جاتا ہے؛ “IPset ipsum” کاؤنٹر دکھاتا ہے کہ احتیاطاً کتنے روکے گئے۔فرق سادہ ہے: ری ایکٹو — “انہوں نے حملہ کیا اور بین ہوئے”، پرو ایکٹو — “انہیں کوشش سے پہلے ہی بلاک کر دیا گیا”۔ پہلے recidive میں مصنوعی طور پر ipsum کی list-3 ڈالی جاتی تھی (اسی سے پرانا “فہرستی recidive” بٹوارہ)؛ اب recidive صرف حقیقی عادی مجرموں کے لیے ہے، اور احتیاطی بلاک مکمل طور پر فائروال پر ہے۔
ipsum — نقصان دہ IP کی عوامی فہرست، جو روزانہ اپ ڈیٹ ہوتی ہے۔ مانیٹر ڈیش بورڈ اور اٹیک میپ پر لوڈ شدہ پتوں کی تعداد دکھاتا ہے اور اسے سیکیورٹی اسکور میں شمار کرتا ہے (−10، اگر سیٹ لوڈ نہ ہو)۔
fail2ban کے بغیر کم از کم آپشن — iptables کے ذریعے بلاکنگ کے ساتھ ایک الگ ipsum سیٹ:
@reboot پر لگائیں۔ ساتھ ہی create … -exist کمانڈ maxelem 300000 کی حد مقرر کرتی ہے (ڈیفالٹ 65536 — level 1 نہیں سماتا، “Hash is full” آئے گا):
ipsum سیٹ میں لوڈ کرتا ہے اور، اگر فائروال کو انسٹالر سنبھالتا ہے (تازہ VPS — “مکمل”/“ہلکا” پروفائل)، تو سیٹ کو DROP رول کے ذریعے UFW سے منسلک کر دیتا ہے — ان IP سے آنے والا ٹریفک واقعی بلاک ہو جاتا ہے۔ رول ESTABLISHED,RELATED کے بعد رکھا جاتا ہے، اس لیے موجودہ کنکشن (بشمول آپ کا SSH) نہیں ٹوٹتے — صرف فہرست سے نئے کنکشن کاٹے جاتے ہیں۔ سیٹ ipsum-load.service سروس کے لوڈ ہونے پر فائروال سے پہلے بحال ہوتا ہے (ورنہ UFW اٹھ نہ پاتا)، اور کرون کے ذریعے 04:00 پر اپ ڈیٹ ہوتا ہے۔ پہلے سے کنفیگر شدہ سرور پر (پینل، اپنا فائروال) انسٹالر فائروال میں مداخلت نہیں کرتا — وہاں ipsum ڈیش بورڈ اور اٹیک میپ کے لیے فہرست ہی رہتا ہے، اور DROP رول چاہیں تو دستی طور پر شامل کیا جاتا ہے (کم از کم آپشن iptables … --match-set ipsum … -j DROP کے ساتھ — اوپر ہے)۔ خودکار انسٹالیشن میں دستی طور پر کچھ کرنے کی ضرورت نہیں۔
اجتماعی threat intelligence کے ساتھ Fail2ban کا جدید متبادل: کمیونٹی کی جانب سے بلاکس کے علاوہ اپنے قواعد۔ فائر وال پر بلاکس لاگو کرنے کے لیے علیحدہ bouncer درکار ہے۔
systemctl is-active crowdsec کے ذریعے چیک کرتا ہے)۔ چلانے کے لیے: sudo systemctl enable --now crowdsec؛ کریش ہونے پر دیکھیں sudo journalctl -u crowdsec -n 30۔ یہی اصول “نہیں چل رہا” اسٹیٹس والی ہر سروس پر لاگو ہوتا ہے (Suricata, Falco, Monit, MySQL)۔
stream halted / بلاکس لاگو نہیں ہو رہے۔ یہ ایک لاوارث api-key ہے: bouncer کو cscli bouncers list سے حذف کر دیا گیا تھا، مگر اس کی پرانی key /etc/crowdsec/bouncers/*.yaml میں باقی رہ گئی۔ bouncer کو دوبارہ رجسٹر کریں اور نئی key درج کریں:
AIDE (Advanced Intrusion Detection Environment) فائل سسٹم کا سنیپ شاٹ لیتا ہے اور ہر جانچ پر /etc، /bin، /usr میں تبدیلیوں کی اطلاع دیتا ہے۔ تنصیب کے بعد ڈیٹابیس کی ابتدائی سیٹنگ (aideinit) لازمی ہے۔
aideinit کے دوران ٹرمینل 5–15 منٹ تک Running aide --init... لائن پر رکا رہتا ہے — یہ معمول کی بات ہے (پوری ایف ایس کی ہیشنگ، ڈسک پر بوجھ)۔ Ctrl+C سے نہ روکیں۔ اگر عمل “رُکا” ہوا لگے مگر کچھ نہ لکھے — تو ممکن ہے وہ کسی خفیہ سوال Overwrite existing aide.db.new [Yn]? کے جواب کا منتظر ہو (Y دبائیں)۔ دوسرے سیشن سے سرگرمی جانچیں: pgrep -af aide۔
aideinit کی خرابی: “21_aide_spamassassin … printf: invalid number” (return code 20) — Ubuntu 22.04 میں AIDE کے کنفیگ سنیپٹ کا ایک معروف بگ ہے۔ ڈیٹابیس نہیں بنتی۔ خراب سنیپٹ ہٹا کر دوبارہ کوشش کریں:
aideinit چلایا ہی نہیں گیا، یا (Ubuntu 24.04) ڈائریکٹری /var/lib/aide 700 موڈ میں بنی ہے اور www-data کے لیے ناقابلِ رسائی ہے — اسے sudo chmod 755 /var/lib/aide سے ٹھیک کریں (اوپر والا بلاک دیکھیں)۔ “کوئی جانچ نہیں ہوئی” = ڈیٹابیس موجود ہے مگر جانچ ابھی نہیں ہوئی — یہ خرابی نہیں۔ نتائج مانیٹر /var/log/aide/aide.log سے پڑھتا ہے۔
/etc/cron.daily/aide شاید /var/log/aide/aide.log کو مطلوبہ شکل میں نہ لکھے (اور ان میں aide.wrapper اب موجود ہی نہیں)۔ زیادہ قابلِ اعتماد یہ ہے کہ واضح --config کے ساتھ اپنا کرون شامل کریں — یہ لاگ root سے 644 موڈ میں لکھتا ہے، اور مانیٹر اسے اضافی گروپس کے بغیر پڑھ لیتا ہے:
chmod 755 /var/lib/aide اور 02:00 پر جانچ کا کرون — دستی طور پر کچھ نہیں کرنا پڑتا۔
sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db۔
Linux کے لیے اینٹی وائرس اسکینر۔ PHP شیلز اور نقصان دہ کوڈ کے لیے /var/www کی جانچ میں خاص طور پر مفید ہے۔
enable --now کے بعد clamd ڈیمن “غیر فعال” دکھا رہا ہے؟ تین عام وجوہات:
1. کنفگ میں Example کی سطر باقی رہ گئی ہے — جب تک یہ موجود ہے، clamd شروع ہونے سے انکار کرتا ہے:
2. سگنیچر ڈیٹابیس ڈاؤن لوڈ نہیں ہوا — اس کے بغیر clamd شروع نہیں ہوتا:
3. بس لوڈ ہو رہا ہے — clamd تقریباً 80 لاکھ سگنیچرز کو 30–60 سیکنڈ میں میموری میں لوڈ کرتا ہے۔ انتظار کریں اور جانچیں: systemctl is-active clamav-daemon (اسٹیٹس activating → ابھی لوڈ ہو رہا ہے)۔
sudo journalctl -u clamav-daemon -n 30 --no-pager۔
clamd ڈیمن صرف سگنیچرز کو میموری میں رکھتا ہے، خود شیڈول کے مطابق کچھ اسکین نہیں کرتا۔ پینل منصوبہ بند اسکین کے نتائج دکھاتا ہے، اس لیے ایک کرون درکار ہے جو اسکین کرے اور لاگ لکھے۔ خودکار تنصیب ایک ریپر /usr/local/bin/clamav-scan.sh اور 01:30 پر کرون لگاتی ہے — پہلی بار چلنے کے بعد “جانچی گئی فائلیں” اور “آخری اسکین” بھر جائیں گے۔ شیڈول کا انتظار کیے بغیر فوراً چلائیں: sudo /usr/local/bin/clamav-scan.sh۔
Linux Malware Detect (LMD) — ویب خطرات کے لیے مالویئر اسکینر: PHP شیلز، ویب بیک ڈور، لوڈرز۔ یہ ClamAV انجن استعمال کرتا ہے اور اسے اپنے دستخطوں سے مکمل کرتا ہے۔
maldet --report۔
update-rc.d: error: unable to read /etc/init.d/maldet — یہ بے ضرر ہے۔ maldet init.d استعمال نہیں کرتا، دستخطوں کی اپ ڈیٹ اور اسکین /etc/cron.daily/maldet کے ذریعے چلتے ہیں۔ اگر نیچے installation completed نظر آئے — تو سب کچھ انسٹال ہو گیا۔
apt کے ذریعے نہیں بلکہ /usr/local/maldetect میں انسٹال ہوتا ہے، اور open_basedir فعال ہونے پر اس کی موجودگی shell کے ذریعے چیک کی جاتی ہے — دیکھیں سیکشن “صفحہ خالی ہے حالانکہ سرور پر ڈیٹا موجود ہے”۔
نیٹ ورک دخل اندازی کا پتہ لگانے کا نظام: ٹریفک کا پیکٹ کی سطح پر تجزیہ کرتا ہے اور حملوں کے ہزاروں سگنیچر جانتا ہے۔ ModSecurity کی تکمیل کرتا ہے (وہ HTTP کی سطح پر کام کرتا ہے، Suricata — TCP/IP کی سطح پر)۔
/var/log/suricata/eve.json کو root کے تحت ڈائریکٹری پر 750 موڈ میں لکھتا ہے، اور ویب سرور (www-data) اسے نہیں پڑھ سکتا۔ ڈائریکٹری کو گزرنے کے لیے کھولیں — اندر کی فائلیں محفوظ رہتی ہیں:
eBPF/kernel module کے ذریعے سسٹم کالز کو پکڑتا ہے اور حقیقی وقت میں بے قاعدگیوں کا پتہ لگاتا ہے: nginx سے shell، ویب پروسیس کی جانب سے /etc/passwd کا پڑھنا، /bin میں لکھنا وغیرہ۔
journalctl -u falco کے ذریعے پڑھتا ہے (بغیر sudo — systemd-journal گروپ کے ذریعے)۔ یقینی بنائیں کہ www-data اس گروپ میں ہے — دیکھیں دستی تنصیب کے صفحے پر “sudo کی ترتیب” (نکتہ 2)۔
/etc/passwd کا پڑھنا، سسٹم ڈائریکٹریز میں لکھنا)۔ پُرسکون سرور پر دن بھر میں صفر تشویشناک ایونٹس ایک صحت مند حالت ہے۔
journalctl کے ذریعے پڑھنے کے لیے جرنل تک رسائی کے حقوق درکار ہوتے ہیں؛ تاکہ پینل ایونٹس مستقل طور پر دیکھ سکے، خودکار تنصیب Falco میں file_output → /var/log/falco/falco.log فعال کرتی ہے اور سروس کو UMask=0022 دیتی ہے (لاگ ویب سرور کے ذریعے پڑھا جاتا ہے)۔ نئی تنصیب پر اسے دستی طور پر ترتیب دینے کی ضرورت نہیں۔
ModSecurity — Apache یا Nginx کے لیے ویب فائروال (WAF)۔ ایپلیکیشن سطح پر حملے روکتا ہے: SQL انجیکشن، XSS، پاتھ ٹریورسل، اسکینرز۔
IncludeOptional /etc/modsecurity/*.conf لائن سے شامل کرتا ہے، جبکہ پیکج صرف modsecurity.conf-recommended رکھتا ہے — جو *.conf ماسک میں نہیں آتی۔ اگر اسے modsecurity.conf میں کاپی نہ کیا جائے تو SecRuleEngine Off ہی رہتا ہے: ماڈیول لوڈ ہے، CRS قواعد لوڈ ہیں، مگر ٹریفک جانچی نہیں جاتی اور آڈٹ لاگ نہیں بنتا۔ درمیانی موڈ DetectionOnly صرف واقعات لاگ میں لکھتا ہے، درخواستیں روکتا نہیں — ڈیش بورڈ اسے پیلا دکھاتا ہے۔
آڈٹ لاگ تک ڈیش بورڈ کی رسائی۔ لاگ /var/log/apache2/modsec_audit.log root کی ملکیت ہے (اجازتیں 640)، ویب صارف اسے پڑھ نہیں سکتا۔ ڈیش بورڈ ڈیٹا ایک ریپر کے ذریعے لیتا ہے — اسے بنائیں:
SecRuleEngine ہدایت لیتا ہے: انڈینٹ والی لائنیں <LocationMatch>/<Directory> بلاکس کے اندر ہوتی ہیں (مثلاً phpMyAdmin کے لیے WAF بند کرنا) اور عالمی موڈ متعین نہیں کرتیں۔www-data ہے، HestiaCP میں سائٹ کا پول سائٹ کے مالک (مثلاً admin) کے تحت چلتا ہے — grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf سے جانچیں۔X-Forwarded-For ہیڈر سے لیتا ہے۔ اعدادوشمار میں صرف وہی ٹرانزیکشنز آتی ہیں جن پر کوئی قاعدہ لاگو ہوا: SecAuditLogRelevantStatus ہدایت کسی بھی 4xx/5xx جواب کو آڈٹ لاگ میں لکھتی ہے، اس لیے عام 403/500 بھی وہاں آ جاتے ہیں — ڈیش بورڈ انہیں WAF واقعات شمار نہیں کرتا۔---RULES--- بلاک “تمام فعال قواعد” سیکشن کے لیے ضروری ہے — ڈیش بورڈ صرف لاگو ہونے والے نہیں بلکہ لوڈ شدہ تمام CRS + کسٹم قواعد دکھاتا ہے۔ for f in … لوپ میں تین پاتھ CRS قواعد اور مقامی اضافوں کے لیے عام مقامات ہیں؛ اگر آپ کی ترتیب مختلف ہے (پیکج فائلیں اپنی ڈائریکٹری میں رکھتا ہے، یا کسٹم قواعد /etc/modsecurity/custom-rules.conf میں نہیں ہیں)، تو sudo grep -rl 'IncludeOptional\|^Include ' /etc/apache2/mods-enabled/security2.conf /etc/apache2/conf-enabled/*.conf 2>/dev/null کمانڈ سے حقیقی پاتھ تلاش کریں اور انہیں فہرست میں ڈالیں۔ اگر ریپر پرانا ہے (اس سیکشن کے بغیر) — تو سیکشن صرف “دستیاب نہیں” انتباہ دکھائے گا، باقی صفحہ پہلے کی طرح کام کرتا رہے گا۔
Auditd (Linux Audit Daemon) کرنل کی سطح پر سسٹم کالز کو ریکارڈ کرتا ہے: لاگ اِن اور لاگ آؤٹ، sudo کمانڈز، ناکام تصدیقی کوششیں، فائل تبدیلیاں۔ مانیٹر آج کے لاگ اِن، ناکام کوششیں اور sudo کمانڈز دکھاتا ہے۔
ausearch (/usr/sbin/ausearch) کے ذریعے اور ضرورت پڑنے پر /var/log/audit/audit.log سے tail کمانڈ سے پڑھتا ہے۔ دونوں sudoers میں ہونے چاہئیں۔
سروسز (nginx، php-fpm، mysql وغیرہ) پر نظر رکھتا ہے اور بند ہونے پر انہیں دوبارہ چلاتا ہے۔ email پر الرٹ بھیج سکتا ہے۔
monit status کے ذریعے حاصل کرتا ہے۔ /etc/monit/monitrc میں HTTP انٹرفیس فعال ہونا چاہیے (allow localhost کے ساتھ set httpd بلاک)، ورنہ monit status ایک خرابی واپس کرے گا۔
monitrc میں set httpd کی سطر کمنٹ شدہ ہے (بطورِ ڈیفالٹ یہ # set httpd port 2812 … کے طور پر ہوتی ہے)۔ اس بلاک کو ان کمنٹ کریں اور localhost کی اجازت دیں۔ (2) صرف httpd فعال ہونے سے کچھ ٹریک نہیں ہوتا — Monit صرف وہی گنتا ہے جو check اسٹانزا میں بیان ہو؛ ان کے بغیر انٹرفیس چالو ہونے پر بھی فہرست خالی رہتی ہے۔ کم از کم فعال کنفگ:
conf.d رکھ دیتی ہے — نئی تنصیب پر دستی ترتیب کی ضرورت نہیں۔
PSAD iptables کے لاگ کا تجزیہ کرتا ہے اور پورٹ اسکیننگ اور نیٹ ورک حملوں کی نشاندہی کرتا ہے، ہر ماخذ کو خطرے کا درجہ (1–5) دیتے ہوئے۔ fail2ban اور Suricata کی تکمیل کرتا ہے۔
psad --Status کے ذریعے ڈیٹا پڑھتا ہے (sudoers میں درکار ہے)۔ iptables لاگنگ کے بغیر صفحہ خالی رہے گا — یہ معمول کی بات ہے، جب تک کوئی اسکیننگ نہ ہوئی ہو۔
Mandatory Access Control اس بات کو محدود کرتا ہے کہ کوئی پروگرام کن فائلوں اور وسائل تک رسائی کر سکتا ہے، خواہ اسے ہیک ہی کیوں نہ کر لیا گیا ہو۔ Ubuntu/Debian میں بطورِ طے شدہ AppArmor استعمال ہوتا ہے (عموماً پہلے سے نصب اور فعال ہوتا ہے)۔
aa-status کے ذریعے پڑھتا ہے (sudoers میں درکار ہے)۔ یہ enforce/complain موڈ میں پروفائلوں کی تعداد اور بغیر پروفائل والے پراسیس دکھاتا ہے۔
“لوڈ شدہ پروفائل” کا enforce + complain سے زیادہ ہونا معمول کی بات ہے۔ AppArmor 4.x (Ubuntu 24.04 اور اس سے نئے) میں unconfined موڈ آ گیا ہے: پروفائل کرنل میں لوڈ ہوتا ہے مگر کسی چیز کو محدود نہیں کرتا۔ Ubuntu user namespaces استعمال کرنے والے پروگراموں (براؤزر، torrent کلائنٹ وغیرہ) کے درجنوں پروفائل اسی طرح نشان زد کرتا ہے۔ جب ایسے پروفائل موجود ہوں تو “لوڈ شدہ پروفائل” کارڈ کہربائی رنگ کا ہو جاتا ہے اور ان کی تعداد دکھاتا ہے — مثلاً 120 لوڈ شدہ اور 26 enforce میں ہونے پر unconfined: 90۔ حقیقتاً صرف enforce والے پروفائل ہی تحفظ دیتے ہیں؛ Ubuntu 22.04 (AppArmor 3.x) میں یہ موڈ نہیں اور اعداد ہمیشہ ملتے ہیں۔
unconfined چھوڑا ہے، انہیں enforce میں منتقل کرنا صرف سوچ سمجھ کر کرنا چاہیے: یہ غلطی سے نہیں بلکہ اس لیے بند ہیں کہ ورنہ خود ان پروگراموں کا کام ٹوٹ جاتا ہے۔ complain والے پروفائل الگ معاملہ ہیں: وہاں قواعد پہلے ہی لکھے ہوئے ہیں اور بس لاگو نہیں ہوتے۔
debsums اس بات کی تصدیق کرتا ہے کہ نصب شدہ پیکجز کی فائلیں ریپازٹری کے چیک سمز سے مطابقت رکھتی ہیں — یہ تبدیل کیے گئے سسٹم بائنریز کا پتا لگاتا ہے (AIDE کی تکمیل کرتا ہے)۔ مکمل جانچ میں 1–2 منٹ لگتے ہیں، اس لیے یہ cron کے ذریعے چلتی ہے، اور ڈیش بورڈ نتیجہ data/debsums/debsums.log سے پڑھتا ہے اور خود ہی زمروں میں تقسیم کر دیتا ہے (صرف بائنریز اور لائبریریز اہم ہیں)۔
ٹاسک — root-cron میں (sudo crontab -e)۔ تیار ریپر debsums-scan.sh کو /usr/local/bin/ میں رکھا جاتا ہے (chmod +x؛ cron-ٹاسکس کا خلاصہ دیکھیں) اور یہ خود ہی رپورٹ ڈیش بورڈ کے data/debsums/ میں لکھتا ہے۔
ریپر debsums-scan.sh ڈیش بورڈ کا data/ خود ڈھونڈ لیتا ہے — راستہ درج کرنے کی ضرورت نہیں۔
/etc/ (کنفگز) اور /usr/share/ (ریسورسز) میں تبدیلیاں عام طور پر معمول کی بات ہیں — ڈیش بورڈ انہیں الگ رنگ سے نشان زد کرتا ہے۔ خطرناک وہ ہیں جو بائنریز اور لائبریریز میں ہوں (/bin، /sbin، /usr/lib وغیرہ) — “بائنریز / لائبریریز” کارڈ بالکل انہی کو دکھاتا ہے۔
Lynis کو دستی طور پر یا cron کے ذریعے چلایا جاتا ہے۔ رپورٹ کو پروجیکٹ کے data/lynis/ فولڈر میں محفوظ ہونا چاہیے — مانیٹر lynis-report.dat فائل پڑھتا ہے۔
lynis-scan.sh کو پینل سے براہِ راست پس منظر میں چلاتا ہے (cron کا انتظار کیے بغیر): “اسکیننگ…” دکھاتا ہے اور مکمل ہونے پر خود رپورٹ اپ ڈیٹ کر دیتا ہے۔ اس کے لیے ویب صارف کو اسکرپٹ چلانے کی sudoers لائن درکار ہے — انسٹالر اسے خودکار طور پر /etc/sudoers.d/monitor میں شامل کر دیتا ہے۔ اگر پینل دستی طور پر/پہلے نصب ہوا تھا، تو اسے اسی صارف کے ساتھ درج کریں جو فائل میں پہلے سے موجود ہے:
Logwatch کو روزانہ رپورٹس پروجیکٹ کے data/logwatch/ فولڈر میں .txt فارمیٹ میں محفوظ کرنی چاہئیں۔ مانیٹر تازہ ترین رپورٹ اور آرکائیو دکھاتا ہے۔
نیٹ ورک مانیٹر کو انسٹالیشن کی ضرورت نہیں — یہ ڈیش بورڈ کا ایک بلٹ اِن صفحہ ہے۔ یہ سرور کی نیٹ ورک حالت مقامی ذرائع سے دکھاتا ہے:
/proc/net/dev سے؛ip کے ذریعے؛ss کے ذریعے؛journalctl -k کے ذریعے۔پہلے تین ذرائع sudo کے بغیر کام کرتے ہیں، اس لیے انٹرفیس، ٹریفک، کنکشنز اور پورٹس فوراً نظر آتے ہیں۔ “کرنل ایونٹس” بلاک journalctl -k استعمال کرتا ہے — یہ systemd-journal گروپ کے ذریعے پڑھا جاتا ہے (“sudo کی ترتیب”، نکتہ 2)، sudo درکار نہیں۔ یہ جانچیں کہ سب کچھ ویب یوزر کو دستیاب ہے:
UFW BLOCK ریکارڈز یہاں نہیں آتے — وہ “UFW فائر وال” اور “حملوں کا نقشہ” صفحات پر ہیں۔ سبز نشان کے ساتھ خالی بلاک = دن بھر کوئی نیٹ ورک خرابی نہیں ہوئی۔
بلٹ اِن صفحہ تین چیزیں دکھاتا ہے:
df)؛ ≥90% پر پیمانہ سرخ ہو جاتا ہے؛lsblk)، صرف حقیقی (loop/snap چھپے ہوئے)؛smartctl)۔جگہ اور ڈیوائسز کی فہرست بغیر کسی سیٹنگ کے فوراً کام کرتی ہے۔ SMART کے لیے smartmontools پیکج درکار ہے۔ ویب پروسیس کو ڈسک ڈیوائسز تک براہِ راست رسائی نہیں ہوتی، اس لیے SMART کو cron کے ذریعے data/disk/smart.txt فائل میں لیا جاتا ہے، اور ڈیش بورڈ اسے پڑھتا ہے۔
ٹاسک — root-cron میں (sudo crontab -e)۔ تیار شدہ ریپر smart-scan.sh کو /usr/local/bin/ میں رکھا جاتا ہے (chmod +x؛ cron-ٹاسکس کا خلاصہ دیکھیں) اور یہ خود ڈیش بورڈ کے data/disk/ میں لکھتا ہے۔
ریپر smart-scan.sh خود ڈیش بورڈ کا data/ ڈھونڈ لیتا ہے — راستہ لکھنے کی ضرورت نہیں۔ اندرونی طور پر lsblk -e7,11 loop/cdrom کو خارج کر دیتا ہے۔
یہ صفحہ گزشتہ 24 گھنٹوں میں سرور کے بوجھ کی تاریخ دکھاتا ہے — Load Average، CPU کا استعمال اور I/O انتظار، RAM/Swap، نیٹ ورک ٹریفک (وصولی/ترسیل)، ڈسک I/O (پڑھائی/لکھائی)، ڈسک اور inodes کی بھرائی، کھلے فائل ڈسکرپٹرز اور MySQL کنکشنز، نیز TCP کنکشنز اور پراسیسز کی موجودہ تعداد۔
ڈیٹا cron/collect_metrics.php جمع کرتا ہے — ہر 5 منٹ میں کاؤنٹرز کا ایک “خام” سنیپ شاٹ (/proc/loadavg، /proc/meminfo، /proc/stat، /proc/net/dev، /proc/diskstats، df/df -i، /proc/sys/fs/file-nr، SHOW GLOBAL STATUS LIKE 'Threads_connected') ڈیٹابیس ٹیبل system_metrics میں لکھتا ہے؛ فیصد اور رفتاریں صفحہ خود ملحقہ سنیپ شاٹس کے فرق سے حساب کرتا ہے (ڈسک/inodes/ڈسکرپٹرز/MySQL کنکشنز کی بھرائی — فوری قدریں، بغیر دوبارہ حساب کے)۔ Sudo درکار نہیں — ذرائع root حقوق کے بغیر پڑھے جاتے ہیں۔ 24 گھنٹے سے پرانے پوائنٹس ہر لکھائی پر خودکار طور پر حذف ہو جاتے ہیں۔
ریپر collect-metrics-all.sh (cron ٹاسکس کا خلاصہ دیکھیں) خود سرور پر پینل کے تمام نصب شدہ انسٹینسز تلاش کرتا ہے اور ہر ایک کا cron/collect_metrics.php سائٹ مالک کی طرف سے چلاتا ہے۔
بوجھ کے انتباہات (“ترتیبات” → “بوجھ کے انتباہات” سیکشن) — CPU/RAM/ڈسک/inodes کی حد سے تجاوز پر پینل Telegram/Email میں اطلاع بھیجتا ہے (وہی چینلز جو یومیہ رپورٹ کے ہیں — انتباہات کے لیے انہیں الگ سے فعال کرنے کی ضرورت نہیں)، اور ایک اور اطلاع جب میٹرک معمول پر واپس آ جائے۔ حد برقرار رہنے کے دوران دوبارہ اسپیم نہیں کرتا: اگلی اطلاع صرف “بحال ہوا → دوبارہ تجاوز کیا” کے چکر کے بعد آئے گی۔
collect_metrics.php ہر چلنے پر کرتا ہے (ہر 5 منٹ میں) — الگ cron کی ضرورت نہیں۔ “پہلے ہی اطلاع دی / ابھی نہیں” کی حالت data/alerts_state.json میں محفوظ ہوتی ہے، حدود — پینل کی ترتیبات میں۔
“حملوں کا نقشہ” صفحہ geoiplookup کمانڈ کے ذریعے IP سے ملک کا تعین کرتا ہے۔ GeoIP پیکج کے بغیر ممالک کا تعین نہیں ہوگا اور نقشے پر نقطے ظاہر نہیں ہوں گے:
/usr/share/GeoIP/GeoIP.dat ڈیٹابیس سب پڑھ سکتے ہیں، نتائج tmp/geoip_cache.json میں کیش ہوتے ہیں۔ نقشہ خود (Leaflet + OpenStreetMap ٹائلز) براؤزر میں لوڈ ہوتا ہے — جس کمپیوٹر پر ڈیش بورڈ کھلا ہے وہاں انٹرنیٹ درکار ہے۔
ڈیش بورڈ کے دو بلٹ اِن کارڈ جو کسی ٹول کے “آن/آف” ہونے کے بجائے سرور کی حقیقی حفاظت دکھاتے ہیں۔ انسٹالیشن کی ضرورت نہیں، sudo کے بغیر مقامی طور پر پڑھے جاتے ہیں۔
بیرونی نمائش — کتنی سروسز تمام انٹرفیسز (0.0.0.0/[::]) پر سن رہی ہیں اور باہر سے قابلِ رسائی ہیں۔ اگر باہر کی طرف DBMS یا کیش (MySQL, PostgreSQL, Redis, MongoDB, Memcached, Elasticsearch) کھلا ہو تو یہ سرخ نشان دیتا ہے — یہ براہِ راست خلا ہے (سیکیورٹی اسکور میں −10)۔ ماخذ: ss -tuln۔
127.0.0.1 سے منسلک کریں (MySQL/PostgreSQL کانفگ میں bind-address، Redis میں bind 127.0.0.1) یا UFW میں پورٹ بند کریں۔
127.0.0.1 (loopback) پر سن رہی ہو وہ صرف خود سرور کو نظر آتی ہے — باہر سے اس تک نہیں پہنچا جا سکتا، چاہے پورٹ “کھلا” ہو۔ اسی لیے پورٹ 25 پر Postfix جو loopback سے منسلک ہے محفوظ ہے: خودکار سیٹ اپ inet_interfaces = loopback-only لگاتا ہے (اور نیوٹرل smtpd_banner — جو ورژن ظاہر ہونے سے متعلق Lynis کا اعتراض MAIL-8818 بند کر دیتا ہے)۔ “بیرونی نمائش” کارڈ باہر صرف اسی کو گنتا ہے جو 0.0.0.0/[::] پر سن رہا ہو؛ loopback سروسز اس میں شامل نہیں ہوتیں۔
/etc/postfix/main.cf میں smtpd_banner = $myhostname ESMTP (ورژن اور OS کے بغیر) اور inet_interfaces = loopback-only مقرر کریں، پھر sudo systemctl restart postfix۔
سیکیورٹی اپڈیٹس — کتنے security پیچ انسٹال ہونے کے منتظر ہیں اور کرنل اپڈیٹ کے بعد ری بوٹ کی ضرورت ہے یا نہیں (پیچ موجود ہونے پر سیکیورٹی اسکور میں −5)۔ ماخذ: /usr/lib/update-notifier/apt-check، فائل /var/run/reboot-required۔ تفصیلی فہرست — “سیکیورٹی اپڈیٹس” صفحے پر۔
update-notifier-common) پر کام کرتا ہے۔ اگر apt-check موجود نہ ہو — مانیٹر پیچ apt-get -s upgrade کے ذریعے گنتا ہے۔
خودکار سیکیورٹی اپڈیٹس (unattended-upgrades) — “سیکیورٹی اپڈیٹس” صفحے پر ایک الگ کارڈ دکھاتا ہے کہ security پیچ کی خودکار انسٹالیشن فعال ہے یا نہیں اور یہ آخری بار کب چلی۔ Sudo کی ضرورت نہیں — حیثیت apt-config dump کے ذریعے پڑھی جاتی ہے۔
بیک اپ سب سے بڑی حفاظت ہے: ڈیٹا کا ضیاع کسی بھی ہیک سے زیادہ خطرناک ہوتا ہے۔ دو چیزیں درکار ہیں — سرور/سائٹس کا بیک اپ اور الگ سے پینل کے ڈیٹا بیس کا بیک اپ (اس میں صارفین، WebAuthn کیز، ترتیبات اور لائسنس ہوتے ہیں)۔
طریقہ A — HestiaCP: صارف کے پاس Backup ٹیب → بیک اپ بنانے کا بٹن (یا سرور کی ترتیبات میں شیڈول کے مطابق)۔ بیک اپ میں سائٹس اور اُن کے ڈیٹا بیس شامل ہوتے ہیں۔
طریقہ B — دستی (cron): ڈیٹا بیس کا ڈمپ + پینل کی data/ ڈائریکٹری کا آرکائیو:
نئے ورژن پر اپڈیٹ کریں۔ پہلے بیک اپ بنائیں۔ پھر کوڈ کی فائلیں دوبارہ اپلوڈ کریں، اپنا ڈیٹا محفوظ رکھتے ہوئے:
public/، includes/، assets/، cron/، database/، اور روٹ کی .htaccess (فرنٹ کنٹرولر — راؤٹنگ کو پرانے ورژن سے نہیں رکھا جا سکتا)، manifest.json، sw.js؛config.php (DB کا ڈیٹا)، data/ (رپورٹس)، logs/، tmp/ (سیشنز اور کیش)۔SSH_FX_PERMISSION_DENIED — Permission denied دکھاتا ہے۔ پینل کی فائلیں www-data کی ملکیت ہیں (تنصیب کے وقت ایسے ہی سیٹ کی گئی تھیں)، جبکہ SFTP کلائنٹ آپ کے اپنے صارف سے جڑتا ہے جس کے پاس لکھنے کا اختیار نہیں۔ پوری پینل www-data کو دے دینا “تاکہ کام کرے” — بالکل وہی ہے جو اس خرابی کا سبب بنتا ہے؛ نیچے تین طریقے ہیں، کوئی بھی مسئلہ حل کر دیتا ہے۔
data/ (رپورٹس)، tmp/ (سیشنز اور کیش)، logs/؛ یہ www-data کے پاس رہتی ہیں۔ باقی سب کوڈ ہے، اور ویب سرور کو اس کی صرف پڑھنے کی ضرورت ہے، جو 644 اختیارات کے ساتھ www-data گروپ دیتا ہے۔ ضمنی فائدہ: PHP میں خامی ہونے پر پینل کی فائلیں دوبارہ نہیں لکھی جا سکتیں۔ ہوسٹنگ پینلز (HestiaCP وغیرہ) پر طریقہ A کی ضرورت نہیں: وہاں سائٹ کی فائلیں ویسے ہی اس اکاؤنٹ کی ملکیت ہوتی ہیں جس سے آپ SFTP پر داخل ہوتے ہیں، اور ویب سرور انہیں گروپ کے ذریعے پڑھتا ہے۔
chmod ACL ماسک کو ری سیٹ کر دیتا ہے، اور رسائی خاموشی سے ختم ہو جاتی ہے۔ اگر “اختیارات میں ترتیب لگانے” کے بعد اپلوڈ دوبارہ Permission denied پر اٹک جائے — دونوں setfacl کمانڈز دہرائیں۔
2 کا بٹ ہی setgid ہے: SFTP سے اپلوڈ کی گئی فائلیں www-data گروپ میں رہتی ہیں، ورنہ پینل انہیں دوبارہ نہیں لکھ سکے گا۔ طریقہ C کے بعد FileZilla میں دوبارہ کنیکٹ کریں — نیا گروپ صرف نئے لاگ اِن پر لاگو ہوتا ہے۔ جانچ: id deploy (www-data گروپ نظر آنا چاہیے) اور ls -ld /path/to/monitor (drwxrwsr-x — s کا مطلب ہے کہ setgid لگا ہوا ہے)۔
دوسرے سرور پر منتقلی:
config.php، data/ کے ساتھ کاپی کریں۔mysqldump → نئے پر امپورٹ؛ config.php میں DB کا ڈیٹا درست کریں۔adm گروپ کی رکنیت، cron کام۔اگر آپ لاگ اِن نہیں کر پا رہے — سب کچھ سرور سے براہِ راست ڈیٹابیس میں ٹھیک ہو جاتا ہے۔ ڈیٹابیس کھولیں (نام — config.php سے):
WebAuthn security key کھو گئی (دوسرا فیکٹر مکمل نہیں ہوتا) — 2FA بند کریں، پاس ورڈ سے لاگ اِن کریں، نئی security key رجسٹر کریں:
پاس ورڈ بھول گئے — نیا ہیش سیٹ کریں (اسے سرور پر جنریٹ کر کے یہاں لگائیں):
IP فلٹر سے خود کو بلاک کر لیا — پابندی بند کریں:
sudo mysql، یا phpMyAdmin / ہوسٹنگ پینل کا ڈیٹابیس سیکشن۔ بحالی کے بعد WebAuthn اور IP فلٹر دوبارہ فعال کریں۔
جابز کا خلاصہ — سرور کے root-cron میں (sudo crontab -e کے ذریعے شامل کیے جاتے ہیں)۔ صرف اُن ٹولز کی سطریں رہنے دیں جو آپ استعمال کرتے ہیں؛ راستے اپنے سرور کے مطابق درست کریں۔
sudo crontab -l اور یہ کہ cron سروس فعال ہے۔
config.php کا TIMEZONE۔ TIMEZONE کونسٹنٹ صرف PHP پر اثر ڈالتا ہے (ڈیش بورڈ تاریخیں کیسے دکھاتا ہے)، لیکن cron ڈیمن جابز کو OS کے سسٹم وقت کے مطابق چلاتا ہے۔ اگر سرور کا زون آپ کے زون سے مختلف ہے تو “08:00” رپورٹ غلط وقت پر آئے گی۔ مثال: سرور دوسرے زون میں ہے (Asia/Dubai، UTC+4) اور آپ کراچی میں ہیں (UTC+5) → “08:00” رپورٹ آپ کے مطابق 09:00 پر آئے گی۔ جانچیں اور ضرورت ہو تو سسٹم کا زون اپنے مطابق کریں:
0 8 * * * سطر مقامی وقت کے مطابق 08:00 پر چلے گی۔ ورنہ خود cron کو شفٹ کرنا پڑتا، مگر سرمائی/گرمائی وقت کی تبدیلی پر شفٹ دوبارہ بگڑ جائے گا — اسی لیے سسٹم کا زون سیٹ کرنا زیادہ درست ہے۔
crontab.txt) پروجیکٹ کے ساتھ system/ فولڈر میں ہیں، public_html سے باہر۔ یہ سائٹ کا حصہ نہیں — انہیں ویب روٹ میں اپلوڈ کرنے کی ضرورت نہیں؛ انہیں سرور پر سسٹم راستوں پر رکھیں (جیسے اوپر crontab میں ہے):
lynis-scan.sh → /usr/local/bin/ (chmod +x) — lynis audit system چلاتا ہے، اسکین کے دوران /tmp/lynis-running فلیگ رکھتا ہے اور lynis-report.dat کو ڈیش بورڈ کے data/lynis/ میں کاپی کرتا ہے؛logwatch_daily.sh → /usr/local/bin/ (chmod +x) — روزانہ Logwatch رپورٹ (sshd, fail2ban, sudo, postfix) data/logwatch/ میں بناتا ہے؛smart-scan.sh → /usr/local/bin/ (chmod +x) — ڈسکوں کی حالت (smartctl) data/disk/ میں لیتا ہے؛debsums-scan.sh → /usr/local/bin/ (chmod +x) — پیکیجز کی انٹیگریٹی (debsums) data/debsums/ میں جانچتا ہے؛clamav-scan.sh → /usr/local/bin/ (chmod +x) — خطرناک راستوں (web, home, temp) پر ClamAV اینٹی وائرس اسکین؛ خلاصہ /var/log/clamav/scan.log میں لکھتا ہے، جہاں سے اسے ClamAV صفحہ پڑھتا ہے (اوپر crontab میں 01:30 سطر)؛load-ipsum.sh → /usr/local/bin/ (chmod +x) — ipsum ipset سیٹ (level 1) کو اُسی جگہ اپڈیٹ کرتا ہے، فعال فائروال قواعد توڑے بغیر (اوپر crontab میں 04:00 سطر)؛daily-report-all.sh → /usr/local/bin/ (chmod +x) — ڈیش بورڈ کی cron/daily_report.php رپورٹ چلاتا ہے (اوپر crontab میں 08:00 سطر)؛daily_report.php — پہلے سے ڈیش بورڈ میں شامل ہے (cron/daily_report.php)، daily-report-all.sh کے ذریعے چلتا ہے، الگ سے رکھنے کی ضرورت نہیں؛collect-metrics-all.sh → /usr/local/bin/ (chmod +x) — ڈیش بورڈ کی cron/collect_metrics.php چلاتا ہے (صفحہ “کارکردگی”، اوپر crontab میں */5 سطر)؛ collect_metrics.php پہلے سے ڈیش بورڈ میں شامل ہے، الگ سے رکھنے کی ضرورت نہیں؛crontab.txt (system/cron/) — جابز کا نمونہ؛ درکار سطریں sudo crontab -e کے ذریعے درج کریں۔/usr/local/bin/ میں کیسے رکھیں۔ FileZilla سے براہِ راست وہاں نہیں لکھا جا سکتا — ڈائریکٹری root کی ملکیت ہے، اور SFTP کلائنٹ کو SSH_FX_PERMISSION_DENIED ملے گا۔ طریقہ یہ ہے: پہلے فائل کو /tmp میں اپلوڈ کریں (وہاں سب لکھ سکتے ہیں)، پھر اسے ایک ہی کمانڈ سے اپنی جگہ منتقل کریں:
/tmp درکار ہے — نہ /var/tmp اور نہ خود ڈیش بورڈ کے اندر tmp/ (آخری www-data کی ملکیت ہے اور آپ کے یوزر سے بند ہے)۔ FileZilla کے درخت میں /tmp اوپری سطح کی شاخ ہے، var کے ساتھ، نہ کہ اُس کے اندر۔
/usr/local/bin/ میں، لاگ — /var/log/arciveo-cron.log) — دستی طور پر کچھ کرنے کی ضرورت نہیں۔
/home/*/web/*/public_html اور /var/www/* چھان کر تلاش کرتے ہیں اور رپورٹیں اُن کے data/ میں رکھتے ہیں۔ اگر ڈیش بورڈ کسی اور راستے پر ہے — اسے اسکرپٹس کے اندر for app in … سطر میں شامل کریں، ورنہ Lynis/SMART/debsums/Logwatch کی رپورٹیں ڈیش بورڈ میں نہیں پہنچیں گی۔
logs/cron.log فائل سب سے پہلے root-cron بناتا ہے — یہ root کی ملکیت ہوگی، اور ڈیش بورڈ میں “cron لاگ” ٹیب نہ اسے پڑھ پائے گا نہ صاف کر پائے گا۔ فائل پہلے ہی ویب یوزر کے نام سے بنا دیں (سائٹ ڈائریکٹری کا مالک؛ HestiaCP پر یہ اکاؤنٹ ہے، مثلاً admin) — تب root-cron صرف اضافہ کرے گا، مالک تبدیل نہیں کرے گا:
stat -c %U /path/to/monitor۔
sudo crontab -e)، ورنہ وہ دو بار چلے گی۔
sudo crontab نہیں (یہ ہر اُس شخص کے لیے براہِ راست root تک اضافہ ہوتا جو ڈیش بورڈ سیشن تک رسائی پا لے)، بلکہ دو کمانڈز (list/set) والا ایک محدود اسکرپٹ، جو صرف خدماتی تبصروں کے درمیان اپنے بلاک کو چھوتا ہے۔ ایک بار انسٹال کریں:
www-data سے مختلف ہو سکتا ہے — جانچیں کہ سائٹ کا PHP-FPM پول کس کے تحت چلتا ہے (ps -o user= -C php-fpm) اور اسے sudoers سطر میں رکھیں۔
public/crontab_monitor.php فائل FTP/SFTP کے ذریعے کسی دوسرے سسٹم یوزر (مثلاً root) کے تحت اپلوڈ ہوئی ہے جبکہ باقی سائٹ فائلیں کسی اور کے تحت، تو ویب سرور اسے پڑھ نہیں سکے گا۔ مالک اور حقوق کو ساتھ والی فائل سے ملائیں اور مطابق کریں:
مانیٹر ٹولز کی موجودگی dpkg-query — APT پیکج ڈیٹابیس — کے ذریعے پہچانتا ہے۔ اگر ٹول apt کے ذریعے انسٹال نہ ہوا ہو (دستی طور پر، snap سے یا سورس سے)، تو dpkg اسے نہیں دیکھ پاتا۔
500 خرابی — PHP، nginx اور خود monitor کی لاگز چیک کریں:
www-data کے تحت نہیں بلکہ صارف کے اکاؤنٹ کے تحت چلتا ہے (مثلاً admin — سائٹ ڈائریکٹری کا مالک)۔ تمام sudo قواعد اور گروپ رکنیت (adm، systemd-journal) کو اسی صارف پر لکھنا ضروری ہے، ورنہ سروسز چلنے کے باوجود ماڈیولز “غیر فعال / 0” دکھائیں گے۔ PHP کا اصل صارف جاننے کے لیے: ps -o user= -C php-fpm | sort -u یا سائٹ ڈائریکٹری کا مالک stat -c '%U' /path/to/monitor۔ آگے نیچے دی گئی تمام کمانڈز میں www-data کی جگہ اسے استعمال کریں۔ خودکار انسٹالیشن ویب صارف خود پہچانتی ہے اور اسی پر sudoers لکھ دیتی ہے۔
ڈیٹا ظاہر نہیں ہوتا — تقریباً ہمیشہ sudo اجازتیں مقرر نہ ہونے کی وجہ سے۔ مخصوص کمانڈ ویب صارف کے نام سے چیک کریں (www-data کی جگہ اپنا لکھیں)۔ فلیگ -n = بغیر پاس ورڈ، جیسے PHP میں ہوتا ہے — اگر پاس ورڈ مانگے تو sudoers میں قاعدہ موجود نہیں:
sudo aa-status پروفائلز دکھاتا ہے، مگر صفحہ “AppArmor” — “غیر فعال”)۔ وجہ: ویب صارف کے پاس اس ماڈیول کی کمانڈ پر sudo اجازت نہیں۔ اوپر کی فہرست سے اسے چیک کریں: اگر پاس ورڈ مانگے تو /etc/sudoers.d/monitor میں غائب سطر شامل کریں (“sudo کی ترتیب”)۔ عام “نئی” کمانڈز: /usr/sbin/aa-status (MAC)، /usr/sbin/psad --Status (PSAD)۔
apache2ctl، ausearch، aa-status یا ss کی اجازت نہ ہو، یا ویب صارف adm/systemd-journal گروپس میں نہ ہو (وہیں سے fail2ban/auth/modsec کی لاگز اور journalctl — Falco اور کرنل ایونٹس پڑھے جاتے ہیں)۔
علامت: سرور پر ڈیٹا موجود ہے (shell کے ذریعے نظر آتا ہے)، مگر صفحہ “کوئی ڈیٹا نہیں” یا غلط اسٹیٹس دکھاتا ہے — مثلاً AIDE “غیر ابتدائی” لکھتا ہے، حالانکہ ڈیٹابیس بن چکا ہے۔
وجہ ہے open_basedir: بہت سے پینل اور ہوسٹنگ PHP-FPM پول کو ڈومین کی ڈائریکٹری تک محدود کر دیتے ہیں، اس لیے سسٹم راستوں (/var/lib/aide، /var/log، /proc…) پر PHP فنکشنز file_exists()، file_get_contents()، filemtime() بلاک ہو جاتے ہیں۔ مانیٹر اس سے بچنے کے لیے ایسے راستے معیاری سسٹم کمانڈز (cat، test، stat) سے پڑھتا ہے۔
open_basedir ہے۔ درست حل سسٹم کمانڈز سے پڑھنا ہے (AIDE اور نیٹ ورک مانیٹر کے لیے پہلے ہی کیا جا چکا ہے)۔ open_basedir کو /var، /proc تک بڑھانے کی ضرورت نہیں اور یہ کم محفوظ ہے۔
مانیٹر پورٹ 443 کے ذریعے ڈومینز سے براہِ راست جُڑ کر سرٹیفکیٹس کی جانچ کرتا ہے۔ اگر ڈومین خود سرور سے قابلِ رسائی نہ ہو یا پورٹ فائروال سے بند ہو تو جانچ مکمل نہیں ہوگی۔
/etc/nginx/sites-enabled/, /etc/nginx/conf.d/) اور Apache (/etc/apache2/sites-enabled/) سے لیتا ہے، اس کے علاوہ HTTP_HOST سے موجودہ ہوسٹ بھی۔
مانیٹر config.php کے صارف کے ذریعے MySQL سے منسلک ہوتا ہے، جس کی رسائی صرف اپنے ہی ڈیٹابیس تک محدود ہے۔ MySQL information_schema میں صرف وہی ڈیٹابیس دکھاتا ہے جن پر مراعات ہوں — اسی لیے باقی نظر نہیں آتے۔
تاکہ مانیٹر تمام ڈیٹابیس دیکھ سکے، اس صارف کو صرف پڑھنے کا حق دیں (ایک بار root سے؛ config.php کا صارف نام لگائیں):
sudo mysql استعمال نہیں کرتا: ڈیٹابیس کی فہرست اس کے اپنے PDO کنکشن سے لی جاتی ہے۔
PostgreSQL کو postgres صارف کی سطح تک رسائی درکار ہے، جو پینل کے ویب صارف کے پاس نہیں ہوتی۔ PHP سے وسیع sudo psql کھولنا غیر محفوظ ہے — اس کے بجائے پینل ایک محدود ریپر بغیر پیرامیٹرز کے چلاتا ہے، جو صرف ورژن، کنکشنز کی تعداد اور سائز کے ساتھ ڈیٹا بیسز کی فہرست پرنٹ کرتا ہے۔ اسے بنائیں:
monitor-pgstat لائن ہٹا دیں (دستی تنصیب کا مرحلہ 13) اور اسکرپٹ خود نہ بنائیں: PostgreSQL کارڈ محض غیر فعال رہے گا۔
پینل دکھاتا ہے کہ کیا ہو رہا ہے؛ نیچے یہ ہے کہ عام صورتوں میں کیا کریں۔ بنیادی اصول: گھبرائیں نہیں، جائز سرگرمی سے تصدیق کریں (آپ کے اپنے اقدامات، اپڈیٹس، بیک اپس)، اور سنجیدگی کے مطابق ردعمل دیں۔
ignoreip میں ہو۔/etc سے باہر، /usr/share سے باہر) — ممکنہ طور پر تبدیلی۔ پیکج کی تصدیق کریں: debsums PACKAGE_NAME، شک ہو تو اسے دوبارہ انسٹال کریں (apt install --reinstall)۔127.0.0.1 سے منسلک کریں یا UFW میں پورٹ بند کریں۔ یہ حقیقی سوراخ ہے۔certbot renew یا پینل کی سیٹنگز دیکھیں)۔sudo apt update && sudo apt upgrade؛ کرنل اپڈیٹ کے بعد سرور ری اسٹارٹ کریں۔