यह 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 एक्सेस के। परिणाम पार्स होकर ब्राउज़र में दिखाए जाते हैं।
स्कोर अधिकतम से शुरू होता है और हर पाई गई समस्या पर घटता है:
PermitRootLogin yes) — −20परिणाम: 80+ = सुरक्षित, 60–79 = ध्यान दें, <60 = ख़तरे में।
WebAuthn — हार्डवेयर की के ज़रिए बिना पासवर्ड प्रमाणीकरण का मानक। YubiKey, Touch ID, Face ID, Windows Hello, Passkey का समर्थन करता है।
पासवर्ड से लॉगिन के बाद सिस्टम पंजीकृत की के ज़रिए पुष्टि माँगता है। पासवर्ड लीक हो जाए तब भी — भौतिक की या बायोमेट्रिक्स के बिना लॉगिन संभव नहीं।
सेटअप के लिए साइड मेनू में WebAuthn कीज़ खोलें और “की पंजीकृत करें” पर क्लिक करें। एक साथ दो कीज़ पंजीकृत करें: यदि एकमात्र की खो जाए या खराब हो जाए, तो उससे पैनल में लॉगिन संभव नहीं होगा।
डैशबोर्ड सुरक्षा रिपोर्ट को Telegram और ईमेल पर भेज सकता है (बटन से और शेड्यूल के अनुसार)। यह “Settings” अनुभाग में सेट किया जाता है।
Telegram. इसके लिए बॉट टोकन और chat id चाहिए:
@BotFather को लिखें → /newbot → 123456:ABC... जैसा टोकन पाएँ।@userinfobot को लिखें, या https://api.telegram.org/bot<TOKEN>/getUpdates खोलें और "chat":{"id":...} ढूँढें।Email. “Settings” → Email में दो तरीके चुन सकते हैं:
re_...) और सत्यापित प्रेषक डोमेन दर्ज करें।रिपोर्ट स्थिति: “ध्यान दें” या “ठीक है”. शीर्षक “ध्यान दें” तभी बनता है जब कोई वास्तविक समस्या हो या कोई कार्रवाई लंबित हो: ClamAV को खतरा मिला, AIDE में फ़ाइल परिवर्तन, Falco की गंभीर घटनाएँ (पिछले 24 घं. में Emergency/Alert/Critical), Monit में गिरी हुई सेवा, रीबूट आवश्यक, SSL समाप्त हो रहा है (≤14 दिन) या security-अपडेट प्रतीक्षारत हैं। पृष्ठभूमि शोर — बॉट्स के 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 उपयोगकर्ता (केवल अपने डेटाबेस तक पहुँच);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-cron में (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 की सार्वजनिक सूची, जो रोज़ाना अपडेट होती है। Monitor डैशबोर्ड और अटैक मैप पर लोड किए गए पतों की संख्या दिखाता है और उसे सुरक्षा स्कोर में गिनता है (−10, यदि सेट लोड न हो)।
fail2ban के बिना न्यूनतम विकल्प — iptables के ज़रिए ब्लॉक करने वाला अलग सेट ipsum:
@reboot पर लगाएँ। साथ ही create … -exist कमांड maxelem 300000 सीमा सेट करती है (डिफ़ॉल्ट 65536 — level 1 समाता नहीं, “Hash is full” आएगा):
ipsum सेट में लोड करती है और, यदि फ़ायरवॉल इंस्टॉलर द्वारा प्रबंधित है (नया VPS — “पूर्ण”/“हल्की” प्रोफ़ाइल), तो सेट को UFW से DROP नियम द्वारा जोड़ती है — इन IP से आने वाला ट्रैफ़िक सचमुच ब्लॉक हो जाता है। नियम ESTABLISHED,RELATED के बाद रहता है, इसलिए मौजूदा कनेक्शन (आपके SSH सहित) नहीं टूटते — केवल सूची से नए कनेक्शन कटते हैं। सेट ipsum-load.service सेवा के लोड होते समय फ़ायरवॉल से पहले बहाल होता है (वरना UFW शुरू ही न होता), और cron द्वारा 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-कुंजी है: bouncer को cscli bouncers list से हटा दिया गया, पर उसकी पुरानी कुंजी /etc/crowdsec/bouncers/*.yaml में रह गई। bouncer को फिर से रजिस्टर करें और नई कुंजी दर्ज करें:
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-कमांड, विफल प्रमाणीकरण प्रयास, फ़ाइल बदलाव। Monitor आज के लॉगिन, विफल प्रयास और sudo-कमांड दिखाता है।
ausearch (/usr/sbin/ausearch) के ज़रिए और ज़रूरत पड़ने पर /var/log/audit/audit.log से tail कमांड द्वारा पढ़ता है। दोनों sudoers में होने चाहिए।
सेवाओं (nginx, php-fpm, mysql आदि) पर नज़र रखता है और बंद होने पर उन्हें फिर से चालू करता है। ईमेल पर अलर्ट भेज सकता है।
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 रखता है जिसमें httpd 2812 पर और जाँचों का सेट शामिल होता है — नई इंस्टॉलेशन पर मैन्युअल रूप से कॉन्फ़िगर करने की ज़रूरत नहीं।
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 फ़ायरवॉल” और “अटैक मैप” पेजों पर हैं। हरे टिक के साथ खाली ब्लॉक = पिछले 24 घंटे में कोई नेटवर्क विफलता नहीं हुई।
अंतर्निहित पेज तीन चीज़ें दिखाता है:
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') DB तालिका system_metrics में लिखता है; प्रतिशत और गति पेज स्वयं पड़ोसी स्नैपशॉट के अंतर से गणना करता है (डिस्क/inodes/डिस्क्रिप्टर/MySQL कनेक्शन भराव — तात्कालिक मान, बिना पुनर्गणना के)। Sudo की ज़रूरत नहीं — स्रोत root अधिकारों के बिना पढ़े जाते हैं। 24 घंटे से पुराने बिंदु हर लेखन के साथ स्वतः हट जाते हैं।
रैपर collect-metrics-all.sh (cron कार्यों का सारांश देखें) स्वयं सर्वर पर स्थापित सभी पैनल इंस्टेंस ढूँढता है और प्रत्येक का cron/collect_metrics.php साइट के स्वामी के नाम से चलाता है।
लोड अलर्ट (“सेटिंग्स” → “लोड अलर्ट” अनुभाग) — CPU/RAM/डिस्क/inodes की सीमा पार होने पर पैनल Telegram/Email में सूचना भेजता है (वही चैनल जो दैनिक रिपोर्ट के लिए हैं — अलर्ट के लिए इन्हें अलग से चालू करने की ज़रूरत नहीं), और एक और तब — जब मेट्रिक सामान्य पर लौट आती है। सीमा बनी रहने के दौरान बार-बार स्पैम नहीं करता: अगली सूचना केवल “सामान्य हुआ → फिर पार हुआ” चक्र के बाद ही आएगी।
collect_metrics.php द्वारा जाँची जाती हैं — अलग 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) पर सुनने वाली सेवा केवल सर्वर को ही दिखती है — पोर्ट “खुला” होने पर भी बाहर से उस तक नहीं पहुँचा जा सकता। इसीलिए loopback से बँधा पोर्ट 25 पर Postfix सुरक्षित है: ऑटो-कॉन्फ़िगरेशन 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 के ज़रिए पढ़ा जाता है।
बैकअप सबसे बड़ी सुरक्षा है: डेटा खोना किसी भी हैक से ज़्यादा भयावह होता है। दो चीज़ें ज़रूरी हैं — सर्वर/साइटों का बैकअप और अलग से पैनल के DB का बैकअप (वहाँ उपयोगकर्ता, WebAuthn कीज़, सेटिंग्स, लाइसेंस होते हैं)।
विकल्प A — HestiaCP: उपयोगकर्ता के लिए Backup टैब → बैकअप बनाने का बटन (या सर्वर सेटिंग्स में शेड्यूल के अनुसार)। बैकअप में साइटें और उनके DB शामिल होते हैं।
विकल्प B — मैन्युअल रूप से (cron): DB डंप + पैनल के 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-जॉब्स।अगर आप लॉग इन नहीं कर पा रहे — सब कुछ सर्वर से सीधे DB में ठीक हो जाता है। DB खोलें (नाम — config.php से):
WebAuthn कुंजी खो गई (दूसरा फ़ैक्टर पार नहीं हो रहा) — 2FA बंद करें, पासवर्ड से लॉग इन करें, नई कुंजी रजिस्टर करें:
पासवर्ड भूल गए — नया हैश सेट करें (उसे सर्वर पर जनरेट करके डालें):
IP फ़िल्टर से खुद को ब्लॉक कर लिया — प्रतिबंध बंद करें:
sudo mysql, या phpMyAdmin / होस्टिंग पैनल का DB सेक्शन। पुनर्प्राप्ति के बाद WebAuthn और IP फ़िल्टर फिर से चालू करें।
कार्यों का सारांश — सर्वर के root-cron में है (sudo crontab -e से जोड़े जाते हैं)। केवल उन्हीं टूल्स की पंक्तियाँ रखें जिनका आप उपयोग करते हैं; पथ अपने सर्वर के अनुसार ठीक करें।
sudo crontab -l और कि cron-सेवा सक्रिय है।
config.php का TIMEZONE नहीं। TIMEZONE स्थिरांक केवल PHP पर असर डालता है (पैनल तिथियाँ कैसे दिखाता है), लेकिन cron-डेमन कार्यों को OS के सिस्टम समय के अनुसार चलाता है। यदि सर्वर का टाइमज़ोन आपके से मेल नहीं खाता, तो “08:00” रिपोर्ट गलत समय पर आएगी। उदाहरण: सर्वर किसी और टाइमज़ोन में है (Asia/Karachi, UTC+5), और आप कोलकाता में हैं (UTC+5:30) → “08:00” रिपोर्ट आपके अनुसार 08:30 पर आएगी। जाँचें और ज़रूरत हो तो सिस्टम का टाइमज़ोन अपने अनुसार करें:
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 फ़ाइल साइट की बाकी फ़ाइलों से भिन्न सिस्टम-उपयोगकर्ता (उदाहरण के लिए root) के तहत FTP/SFTP से अपलोड हुई है, तो वेब-सर्वर उसे पढ़ नहीं पाएगा। पड़ोसी फ़ाइल से मालिक और अनुमतियाँ मिलाएँ और अनुरूप करें:
Monitor टूल की मौजूदगी dpkg-query — APT के पैकेज डेटाबेस के ज़रिए पहचानता है। अगर टूल apt से इंस्टॉल नहीं किया गया (मैन्युअली, snap से या सोर्स से), तो dpkg उसे नहीं देखता।
त्रुटि 500 — PHP, nginx और मॉनिटर के लॉग जाँचें:
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 तक बढ़ाना ज़रूरी नहीं और कम सुरक्षित है।
Monitor पोर्ट 443 के ज़रिए सीधे डोमेन से जुड़कर सर्टिफ़िकेट जाँचता है। अगर डोमेन सर्वर से ही उपलब्ध न हो या पोर्ट फ़ायरवॉल से बंद हो — तो जाँच पूरी नहीं होगी।
/etc/nginx/sites-enabled/, /etc/nginx/conf.d/) और Apache (/etc/apache2/sites-enabled/) से तथा HTTP_HOST के मौजूदा होस्ट से लेता है।
मॉनिटर config.php में दिए गए उस उपयोगकर्ता से MySQL से जुड़ता है, जिसकी पहुँच केवल अपने ही डेटाबेस तक है। MySQL information_schema में केवल उन्हीं डेटाबेस को दिखाता है जिन पर विशेषाधिकार हों — इसलिए बाकी नहीं दिखतीं।
मॉनिटर को सभी DB दिखें, इसके लिए इस उपयोगकर्ता को केवल पढ़ने का अधिकार दें (एक बार 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; कर्नेल अपडेट के बाद सर्वर रीबूट करें।