एक बार, जब मैं छुट्टी से लौटा, तो काफी शरारती था, मैंने PHP में कुछ दिव्य बनाने का फैसला किया। उन्होंने अपने प्रिय डेनवर को खोला और अप्रत्याशित परिवर्तन पर आश्चर्यचकित थे: अपाचे ने 80 वें बंदरगाह को सुनने से पूरी तरह से इनकार कर दिया, जिसका अर्थ है कि इस शाम के लिए मेरे नेक इरादे खतरे में थे। स्थिति, सामान्य रूप से, बहुत अधिक प्रतिबंधात्मक है - तुरंत मेरे सिर में काम करने वाला प्रतिष्ठित ट्रिगर: स्काइप! हालांकि, मेरे आश्चर्य के लिए, स्काइप ने तुरंत इस सेटिंग के विपरीत चेकमार्क की अनुपस्थिति में इस घटना में अपनी गैर-भागीदारी की घोषणा की। अंत में एक विदेशी वीडियोफोन की एल्बी की जांच करने के लिए, मैंने यह देखने का फैसला किया कि अभी भी 80 वें पोर्ट को कौन सुन रहा है।
मैंने जो देखा वह मेरे लिए आशावाद को नहीं जोड़ता था, बल्कि मुझे सोच में अपना मुकुट बना देता था:
PID
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 900
RpcSs
[svchost.exe]
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:990 0.0.0.0:0 LISTENING 2428
WcesComm
[svchost.exe]
TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING 4
यह स्पष्ट हो गया कि अवैध सशस्त्र गिरोह कंप्यूटर पर काम कर रहे थे। इसके अलावा, वे पार्टिसन विधियों के रूप में कार्य करते हैं, क्योंकि पीआईडी = 4 सिस्टम प्रक्रिया से संबंधित है।
पहला विचार दुर्घटना से आया था: अगर कोई बंदरगाह पर सुन रहा है, तो शायद वह वहां कुछ का जवाब दे रहा है, इसलिए, फ़ायरफ़ॉक्स + फायरबग के एक झुंड से लैस होकर, मैंने
लोकलहोस्ट को एक अनुरोध भेजा। अजीब तरह से पर्याप्त, पागल सोचा फल पैदा हुआ है। अज्ञात शत्रु ने उत्तर दिया:
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 25 Sep 2010 11:20:20 GMT
Connection: close
Content-Length: 315तो संदिग्ध का नाम (या उसके साथी) स्पष्ट हो गया: Microsoft-HTTPAPI / 2.0। जानवर मेरे लिए नया है, इस बिंदु तक अपरिचित है, इसलिए जानकारी के लिए वर्ल्ड वाइड वेब के विस्तार में जाने का फैसला किया गया था। Googling, सामान्य रूप से
Habr-Q & A और
askdev.ru में
प्रश्न , विशेष लाभ नहीं लाए। मूल रूप से, लोगों ने एमएस SQL सर्वर या सिस्टम में IIS के अवशेष से कुछ रिपोर्टिंग सेवाओं की ओर इशारा किया। मेरे पास एक या दूसरा नहीं है (हालांकि सिर्फ मामले में, मैंने अभी भी इन संस्करणों को फ़ाइल नामों की गहन खोज के साथ जांचा है)। तो संभावना एक आशाहीन - एक ट्रोजन या एक कीड़ा है। अगले कुछ दिनों (या बल्कि शाम) मैंने विभिन्न एंटी-वायरस सॉफ़्टवेयर का उपयोग करके "अवांछित सॉफ़्टवेयर" के लिए असफल खोजों में खर्च किया। कोई नतीजा नहीं निकला। दूरी में सिस्टम के एक पूर्ण पुनर्स्थापना के भूत को कम कर दिया।
उसी समय, सम्मानित समुदाय के प्रश्न व्यर्थ नहीं थे: एक कॉमरेड ने मूर्खता से फ़ाइल को हटाने का सुझाव दिया c: \ Windows \ System32 \ httpapi.dll, क्योंकि यह वह है जो सभी प्रतिबद्ध अधर्म के लिए जिम्मेदार है। बेशक, मैंने लाइब्रेरी को नहीं हटाया, लेकिन मैंने फ़ाइल पर ध्यान दिया। SysInternals से उपयोगिताओं के साथ लटकाए जाने के बाद, मैं युद्ध में भाग गया:
C:\Windows\system32>tasklist /M httpapi.dll
PID
========================= ======== ============================================
svchost.exe 1328 HTTPAPI.dll
svchost.exe 2628 HTTPAPI.dll
svchost.exe 3856 HTTPAPI.dllटास्कलिस्ट एक मानक विंडोज उपयोगिता है, अनिवार्य रूप से एक कंसोल कार्य प्रबंधक है। / M स्विच के साथ, आप देख सकते हैं कि कौन सी प्रक्रियाएँ दी गई लाइब्रेरी का उपयोग करती हैं। "प्रत्यक्ष निष्पादक" स्पष्ट हो गए। अगला, SysInternals से प्रोसेस एक्सप्लोरर शुरू करते हुए, मुझे दिए गए पहचानकर्ताओं के साथ प्रक्रियाएं मिलीं। प्रॉपर्टीज़ डायलॉग को खोलने पर, सेवा टैब पर, मैंने कुछ अलग-अलग विंडोज़ सेवाएँ देखीं जो इन प्रक्रियाओं में पंजीकृत थीं। कई सेवाएं थीं, इसलिए कोई विकल्प नहीं था - मैंने अपने अनुमान की शुद्धता की जांच करने के लिए सब कुछ बंद कर दिया। सेवाओं में से थे: स्मार्ट कार्ड, ब्रांच कैश, स्मार्ट कार्ड रिमूवल पॉलिसी, होम ग्रुप लिसनर, एसएसडीपी डिस्कवरी, डिस्कवरी प्रोवाइडर होस्ट, आदि। लगभग 15. केवल रिबूट के बाद, मेरे स्थानीय नेटवर्क ने काम करने से इनकार कर दिया (हालांकि इंटरनेट ने अभी भी काम किया है) ), हालांकि, मेरी खुशी के लिए, 80 वें बंदरगाह को मुक्त कर दिया गया था। इसके बाद, एक दिनचर्या थी: उन सेवाओं को चालू करें जो केवल एक-एक करके बंद हो गई थीं और जांचें कि क्या 80 वाँ पोर्ट व्यस्त था। यहां एक छोटी टिप्पणी करना आवश्यक है: तथ्य यह है कि कई सेवाओं को एक ऐसी प्रक्रिया में पंजीकृत किया जाता है जो एक बंदरगाह को सुनता है इसका मतलब यह बिल्कुल नहीं है कि ये सभी सेवाएं इस बंदरगाह को सुन रही हैं। वे सिर्फ "गलत समय पर, गलत जगह पर" निकले। इस प्रकार, हमलावर को काफी सटीक रूप से पहचाना गया: यह ब्रांच कैचेस निकला, जो विवरण से निम्नानुसार है: कैशे नेटवर्क सामग्री स्थानीय सबनेट पर कैशिंग नोड्स से प्राप्त हुई।
खैर, फिर - प्रौद्योगिकी का मामला। MSC पर BranchCache के लिए एक
गाइड खोदा गया था, जिसमें से यह अनुसरण किया गया था कि BranchCache विभिन्न मोड में काम कर सकता है: एक समर्पित सर्वर (आपको सर्वर के रूप में Windows Server 2008 R2 चलने वाली मशीन की आवश्यकता है) और वितरित भंडारण (यह विंडोज 7 के नियमित संस्करणों पर चल सकता है)। तदनुसार, दो चीजें करनी थीं: बंदरगाह को बदलना और वितरित भंडारण के रूप में संचालन का तरीका निर्धारित करना:
REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\PeerDist\DownloadManager\Peers\Connection" /v ListenPort /t REG_DWORD /d 4455 /f
REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\PeerDist\DownloadManager\Peers\Connection" /v ConnectPort /t REG_DWORD /d 4455 /f
netsh br set service mode=distributedउसके बाद, BranchCache को वापस चालू करें और सुनिश्चित करें कि 80 वां पोर्ट मुफ्त है (पोर्ट 4455 अब सुन रहा है)। मुकाबला मिशन सफलतापूर्वक पूरा किया गया है।
UPD : टिप्पणियों में दोस्तों के अनुरोध पर, मैं रिपोर्ट करता हूं कि BranchCache एक नियमित विंडोज सेवा है। आप इसे स्टार्टअप प्रकार: "अक्षम" पैरामीटर में सेट करके अक्षम कर सकते हैं। डिफ़ॉल्ट रूप से, इस सेवा में "मैनुअल" स्टार्टअप प्रकार होता है और इसे आवेदन की मांग पर लॉन्च किया जाता है। इसलिए अधिकांश उपयोगकर्ताओं के लिए, इसे तुरंत अक्षम किया जाना चाहिए।