Ubuntu सिस्टमों की फोरेंसिक ट्राइएज के लिए Python CLI/TUI — आर्टिफैक्ट संग्रह, टाइमलाइन सहसंबंध और Wazuh एकीकरण के साथ पर्सिस्टेंस मैकेनिज़्म का पता लगाता है और उनका उपचार करता है।
लाइव Ubuntu सिस्टम के लिए फ़ॉरेंसिक ट्रायाज — लगभग एक मिनट में स्वचालित आर्टिफ़ैक्ट संग्रह, पर्सिस्टेंस डिटेक्शन, और निर्देशित रेमेडिएशन।
जब आपको संदेह हो कि कोई Linux सिस्टम कंप्रोमाइज़ हो गया है, तो पहले 30-40 मिनट आमतौर पर वही दस कमांड क्रम से चलाने में बीत जाते हैं: चल रही प्रोसेस जाँचना, अजीब cron जॉब्स खोजना, LD_PRELOAD के लिए grep करना, authorized_keys में नई एंट्रीज़ स्कैन करना, sudoers का ऑडिट करना। हर कदम मैनुअल है, बार-बार संदर्भ बदलना पड़ता है, और दबाव में त्रुटि-प्रवण है। एक भी स्रोत छूट जाए — मान लीजिए, केवल /etc/sudoers के बजाय /etc/sudoers.d/, या /etc/cron.d/ के अलावा यूज़र crontabs — और आपके पास अधूरी तस्वीर होगी।
मौजूदा विकल्प इसे साफ़-सुथरे ढंग से हल नहीं करते। lynis एक हार्डनिंग ऑडिटर है, ट्रायाज टूल नहीं — यह एक साफ़ सिस्टम पर कॉन्फ़िगरेशन कमज़ोरियाँ रिपोर्ट करता है और किसी संक्रमित सिस्टम पर शोर पैदा करता है। chkrootkit और rkhunter ज्ञात rootkit सिग्नेचर जाँचते हैं लेकिन नई पर्सिस्टेंस तकनीकों — जैसे दुरुपयोग किए गए systemd timers या वैध दिखने वाली cron एंट्रीज़ — के प्रति अंधे हैं। सामान्य SIEM क्वेरीज़ के लिए लॉग इन्फ्रास्ट्रक्चर चाहिए जो उस सिस्टम पर मौजूद न हो जिसे आप देख रहे हैं। और Volatility जैसे फ़ॉरेंसिक सूट मेमोरी इमेज को लक्षित करते हैं, किसी चल रहे होस्ट पर लाइव शेल को नहीं।
यह अंतराल एक ऐसे टूल का है जो अभी लाइव सिस्टम पर चले, सबसे आम पर्सिस्टेंस वेक्टर कवर करे, लॉग स्रोतों में गतिविधि को एक टाइमलाइन में सहसंबंधित करे, और आपको ठीक-ठीक बताए कि क्या देखना है — बिना किसी बाहरी एजेंट, डेटाबेस, या इंटरनेट कनेक्शन की आवश्यकता के।
ubuntils चार क्रमिक चरणों में चलता है:
/proc, cron टेबल, systemd यूनिट, SSH कुंजियाँ, sudoers फ़ाइलें, environment परिभाषाएँ, पैकेज इंटीग्रिटी (dpkg --verify), PAM/NSS कॉन्फ़िग, और लोडेड kernel मॉड्यूल से समवर्ती रूप से फ़ॉरेंसिक आर्टिफ़ैक्ट एकत्र करते हैं। अधिकांश कलेक्टर एक-दो सेकंड में पूरे हो जाते हैं; dpkg --verify, जो हर इंस्टॉल किए गए पैकेज फ़ाइल को फिर से जाँचता है, सबसे अधिक समय लेता है — एक Ubuntu 26.04 arm64 डेस्कटॉप VM पर पूर्ण स्कैन में 29–68 सेकंड लगे।--rules के साथ लोड किए गए कोई भी कस्टम नियम — एकत्रित आर्टिफ़ैक्ट पर चलाता है, जिससे लगभग एक सेकंड में एक रैंक किया गया, कॉन्फ़िडेंस-स्कोर वाला फ़ाइंडिंग्स लिस्ट तैयार होता है।--json)।ubuntils स्वयं कोई नेटवर्क कॉल नहीं करता, और हर सुविधा — कस्टम नियम और सहसंबंध सहित — स्थानीय रूप से एकत्रित आर्टिफ़ैक्ट पर चलती है। फ़ाइंडिंग्स के होस्ट से बाहर जाने का एकमात्र तरीका Wazuh एकीकरण है: यदि कोई Wazuh एजेंट इंस्टॉल है, तो एक लाइव scan अपनी फ़ाइंडिंग्स को एक स्थानीय फ़ाइल में लिखता है जिसे एजेंट फिर अपने मैनेजर तक भेजता है। किसी रन के लिए इसे बंद करने के लिए --no-wazuh पास करें।
ubuntils scan नीचे दी गई किसी भी चीज़ से अपरिवर्तित है — यह अभी भी 100% लाइव, सिंगल-होस्ट है, और हर मौजूदा फ़्लैग समान रूप से काम करता है। दो अतिरिक्त कमांड, collect और analyze, उसी डिटेक्शन/टाइमलाइन पाइपलाइन को एक ऑफ़लाइन-अनुकूल acquire-then-analyze वर्कफ़्लो में विभाजित करते हैं, उन मामलों के लिए जहाँ आप जाँच के अधीन होस्ट पर सीधे डिटेक्शन नहीं चला सकते (या नहीं चलाना चाहते) — नीचे Offline analysis: collect and analyze देखें, जिसमें इसकी डिटेक्शन-कवरेज संबंधी चेतावनियाँ भी शामिल हैं।
Ubuntu 22.04+ और PEP 668 वाला कोई भी सिस्टम (अनुशंसित):
Ubuntu 22.04+ सिस्टम-व्यापी pip install को ब्लॉक करता है। pipx का उपयोग करें — यह एनवायरनमेंट को पारदर्शी रूप से संभालता है ताकि आपको इसके बारे में कभी सोचना न पड़े:
sudo apt install pipx -y
pipx ensurepath # then open a new shell
git clone https://github.com/asmitdesai/ubuntils.git
cd ubuntils
pipx install -e .
ubuntils scan # not `ubuntils scan` — see below
इसे अपने सामान्य उपयोगकर्ता के रूप में चलाएँ: scan और collect स्वयं को sudo के अंतर्गत पुनः आमंत्रित करते हैं। स्वयं ubuntils … टाइप करना command not found के साथ विफल हो जाता है, क्योंकि sudo के secure_path में ~/.local/bin शामिल नहीं है, जहाँ pipx कमांड रखता है। यदि आपको इसे root शेल से शुरू करना है, तो स्थापित बाइनरी को पथ द्वारा कॉल करें (~youruser/.local/bin/ubuntils scan), या इसके बजाय एक virtual environment में इंस्टॉल करें:
python3 -m venv .venv
.venv/bin/pip install -e .
.venv/bin/ubuntils scan
पुराने सिस्टम / मैनुअल इंस्टॉल:
git clone https://github.com/asmitdesai/ubuntils.git
cd ubuntils
pip install -r requirements.txt -e .
ubuntils scan
ubuntils को पूर्ण आर्टिफैक्ट एक्सेस के लिए रूट की आवश्यकता होती है। यदि आप ubuntils scan को गैर-रूट उपयोगकर्ता के रूप में चलाते हैं, तो यह स्वचालित रूप से उसी Python इंटरप्रेटर (पूर्ण पथ द्वारा) का उपयोग करके sudo के साथ स्वयं को पुनः आमंत्रित करेगा, ताकि आपके PATH को रूट प्रोसेस में अग्रेषित किए बिना सही वातावरण का उपयोग किया जाए। प्रत्येक बाहरी कमांड (ss, dpkg, systemctl, …) एक निश्चित, रूट-स्वामित्व वाले खोज पथ पर हल किया जाता है, कभी भी आपके PATH पर नहीं। रूट के बिना चलाने पर /etc/shadow, कुछ /proc प्रविष्टियाँ, और संरक्षित cron फ़ाइलें छोड़ दी जाएँगी, और प्रत्येक के लिए चेतावनियाँ लॉग की जाएँगी।
केवल डिटेक्शन — इंटरैक्टिव TUI:
ubuntils scan
JSON आउटपुट को फ़ाइल में सहेजकर डिटेक्शन:
ubuntils scan --json > /tmp/triage-$(hostname)-$(date +%Y%m%d).json
CLI remediation preview के साथ पहचान (dry run — कोई बदलाव लागू नहीं किए गए):
ubuntils scan --remediate
CLI उपचार लागू करने के साथ पहचान:
ubuntils scan --remediate --confirm
प्रिंट संस्करण:
ubuntils version
बाद के या ऑफ़लाइन विश्लेषण के लिए एक छेड़छाड़-स्पष्ट बंडल एकत्र करें:
ubuntils collect --output /path/to/bundle.tar.gz
पहले एकत्र किए गए बंडल का विश्लेषण करें (रूट की आवश्यकता नहीं):
ubuntils analyze /path/to/bundle.tar.gz --json
बंडल के बजाय माउंट किए गए फोरेंसिक इमेज या निकाले गए फाइलसिस्टम ट्री का विश्लेषण करें:
ubuntils analyze --root /mnt/forensic-image --json
See ऑफ़लाइन विश्लेषण: एकत्र करें और विश्लेषण करें बंडल प्रारूप के लिए और — महत्वपूर्ण रूप से — लाइव scan की तुलना में ऑफ़लाइन विश्लेषण क्या पता नहीं लगा सकता।