यह सवाल शायद ही कभी अचानक उठता है। सर्वर धीमा हो गया, होस्टिंग ने बाहर जाते ट्रैफ़िक के बारे में लिखा, या मेल में ऐसे लॉगिन की सूचना आई जो आपने नहीं किया था। इसके बाद अप्रिय हिस्सा शुरू होता है: यह साफ़ नहीं होता कि क्या और किस क्रम में देखें, और पहली प्रवृत्ति — सब मिटाकर नए सिरे से लगाना — लगभग हमेशा जल्दबाज़ी होती है।

नीचे जाँच का वह क्रम है जिसमें लगभग बीस मिनट लगते हैं और जो ज़्यादातर मामलों में साफ़ जवाब दे देता है। यह सबसे सस्ती चीज़ से सबसे महँगी की ओर चलता है: पहले वह जो तुरंत दिखता है, फिर वह जिसे किसी मानक से मिलाना पड़ता है।

पहला कदम: कौन लॉगिन हुआ

शुरुआत लॉगिन से। अगर कोई और अंदर आया है, तो लगभग निश्चित रूप से SSH के ज़रिये आया है, और उसका निशान बचा है।

last -20
lastb | head -20
who

last हाल के सफल लॉगिन दिखाता है, lastb असफल, और who वह जो अभी जुड़ा हुआ है। मायने संख्या नहीं, बल्कि उसका ढाँचा रखता है। ऐसे पतों से हज़ारों असफल कोशिशें जो दोबारा लौटते ही नहीं, सामान्य पृष्ठभूमि है; यह हर सार्वजनिक पते पर लगातार चलती है और कुछ नहीं कहती।

चिंता किसी और बात से होनी चाहिए:

  • ऐसे पते से सफल लॉगिन जहाँ आपका कोई नहीं है;
  • ऐसे उपयोगकर्ता नाम से लॉगिन जो आपने कभी बनाया ही नहीं;
  • ऐसे नाम पर असफल कोशिशें जो इस मशीन पर वाकई मौजूद है — इसका मतलब है कि किसी ने शब्दकोश चलाने के बजाय आपके उपयोगकर्ताओं का पता लगा लिया;
  • अभी खुला हुआ ऐसा सत्र जो आपने नहीं खोला।

अलग से देखें कि कोई अनजानी कुंजियाँ तो नहीं आ गईं। फ़ाइल ~/.ssh/authorized_keys अंदर बने रहने का सबसे आम तरीका है: पासवर्ड जितनी बार चाहें बदलें, कुंजी बनी रहती है।

cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys

वहाँ की हर पंक्ति किसी न किसी की पहुँच है। अगर आप नहीं बता सकते कि किसकी, तो उसे पराया मानें।

दूसरा कदम: सिस्टम में क्या बदला

घुसपैठ लगभग हमेशा डिस्क पर निशान छोड़ती है: बदली हुई बाइनरी, कॉन्फ़िग में जुड़ी एक पंक्ति, वेब सर्वर की डायरेक्टरी में नई फ़ाइल। इसे आँख से जाँचना बेकार है — मानक चाहिए।

Debian और Ubuntu पर मानक पहले से मौजूद है: हर पैकेज अपनी फ़ाइलों के चेकसम जानता है।

sudo apt install debsums
sudo debsums -c

कमांड उन फ़ाइलों की सूची देती है जो वितरण की लगाई हुई फ़ाइलों से अलग हैं। कुछ नतीजे जायज़ होंगे — /etc की कॉन्फ़िग फ़ाइलें बदलने के लिए ही होती हैं। लेकिन ऐसे सर्वर पर /usr/bin, /usr/sbin या /bin में बदली हुई चलने योग्य फ़ाइल, जिसे आपने हाथ से नहीं छुआ, बिल्कुल अलग बात है।

दूसरा स्रोत — वहाँ हाल की फ़ाइलें जहाँ कोई नहीं होनी चाहिए। web shell आमतौर पर अपलोड की डायरेक्टरी में बैठता है और एक निर्दोष .php जैसा दिखता है:

find /var/www -type f -name '*.php' -mtime -14 -ls

चौदह दिन सिर्फ़ शुरुआती बिंदु है; वह अवधि लें जिसमें आप निश्चित रूप से कुछ प्रकाशित नहीं कर रहे थे।

तीसरा कदम: बाहर क्या जा रहा है

समझौता किया गया सर्वर शायद ही कभी अपने लिए तोड़ा जाता है। उसका इस्तेमाल होता है: स्पैम भेजने, माइनिंग करने, दूसरे नेटवर्कों तक पहुँचने, किसी और की फ़ाइलें रखने के लिए। यह सब बाहर जाते कनेक्शन बनाता है जो पहले नहीं थे।

ss -tulpn
ss -tp state established

पहली कमांड दिखाती है कि क्या सुन रहा है, दूसरी — अभी क्या जुड़ा है। प्रक्रिया वाला स्तंभ पढ़ें। सवाल किन चीज़ों पर उठते हैं: 0.0.0.0 पर सुनती कोई अनजानी प्रक्रिया; ऐसे पतों के ऊँचे पोर्टों पर बाहर जाते कनेक्शन जिनसे आपके एप्लिकेशन का कोई वास्ता नहीं; और सबसे बढ़कर /tmp या /dev/shm से चली हुई प्रक्रिया — इन डायरेक्टरियों से कुछ भी जायज़ नहीं चलता।

साथ ही लोड देख लें। माइनर खुद को इस तरह खोलता है कि ऐसी साइट पर प्रोसेसर लगातार व्यस्त रहता है जिसकी कोई लोकप्रियता ही नहीं।

अगर संकेत मिल जाएँ

पहली प्रेरणा होती है जल्दी से सफ़ाई कर देना: पराई कुंजी हटाना, प्रक्रिया रोकना, फ़ाइल मिटाना। ऐसा न करें — इसके साथ ही वह चीज़ नष्ट हो जाती है जो बाद में बता सकती थी कि वे अंदर कैसे आए। और अगर यह अनसुलझा रह गया, तो वे लौटेंगे, शायद कल ही।

वह क्रम जो डेटा और तस्वीर दोनों बचाता है:

  1. अगर प्रदाता के पास उपलब्ध हो तो डिस्क का स्नैपशॉट लें। यही एकमात्र कदम है जिसे बाद में दोहराया नहीं जा सकता।
  2. मशीन को नेटवर्क से काट दें, या अपने IP के सिवा सब बंद कर दें — लेकिन बंद न करें। शटडाउन से प्रक्रियाओं की सूची और खुले कनेक्शन खो जाते हैं, और यही आधा सबूत है।
  3. लॉग मशीन से बाहर कॉपी करें: /var/log/auth.log, वेब सर्वर के लॉग, ऊपर की तीनों कमांडों का आउटपुट।
  4. और अब जाकर यह समझें कि वे अंदर कैसे आए।

अगर पहुँच root के अधिकारों के साथ मिली थी, तो साफ़ पुनःस्थापना सही अंत है। कोई भी सफ़ाई इसकी गारंटी नहीं देती कि पीछे कुछ छूटा नहीं। लेकिन कारण समझे बिना दोबारा लगाना बेकार है: आप वही छेद नए सिस्टम पर रख देंगे।

यह सवाल अचानक न आए, इसके लिए

ऊपर की हर चीज़ एक बार की मैनुअल जाँच है, और वह इस सवाल का जवाब देती है कि «अभी क्या हो रहा है»। दिक्कत यह है कि यह सवाल आमतौर पर देर से पूछा जाता है: जब प्रदाता लिख चुका हो या साइट गिर चुकी हो।

इनमें से हर जाँच एक अलग औज़ार के रूप में मौजूद है जो लगातार नज़र रख सकता है: असफल लॉगिन — fail2ban, फ़ाइलों के बदलाव — AIDE, पैकेजों की अखंडता — debsums, खुले पोर्ट — ss का नियमित स्नैपशॉट। इन्हें एक-एक करके लगाना मुश्किल नहीं; मुश्किल है रोज़ लॉगिन करके छह अलग आउटपुट पढ़ने की आदत डालना, और इसीलिए व्यवहार में कोई नहीं पढ़ता।

इन्हें इकट्ठा करने वाले पैनल का पूरा मतलब ठीक यही है: वही डेटा, पर एक पन्ने पर और इतिहास के साथ, ताकि «कल ऐसा नहीं था» अलग से पता लगाए बिना दिख जाए। नीचे डेमो पेज दिखाते हैं कि जुड़ा हुआ यह कैसा लगता है।