इंटेल एएमटी (सक्रिय प्रबंधन प्रौद्योगिकी) टीसीपी / आईपी होस्ट स्टैक के साथ हस्तक्षेप नहीं करता है?

Question

Intel dev किट जो मैं उपयोग कर रहा हूं, उसमें एक दूरस्थ प्रबंधन सुविधा ( यहां उबंटू मैन पेज भी देखें ) शामिल है जो ऑपरेटिंग सिस्टम हैंग होने की स्थिति में रिमोट रीबूट की अनुमति देता है।

यह एक IP पते पर ऑपरेटिंग सिस्टम के साथ साझा करने के लिए मुट्ठी भर बंदरगाहों (16992 और 16993, विशिष्ट होने की) की क्षमता है। (या तो डीएचसीपी अनुरोधों को स्नूपिंग करके या स्वयं जारी करके; मुझे यकीन नहीं है, लेकिन या तो यह इस मोड में एक साझा मैक पते का उपयोग करता है)

मेरे पास यह एक अलग आईपी पते पर चल रहा है, क्योंकि मैं एक संभावित उपयोग के मामले के बारे में चिंतित हूं: एएमटी मेजबान नेटवर्क स्टैक को इसके साथ विरोध करने से कैसे रोकता है?

दूसरे शब्दों में, इंटेल प्रबंधन सॉफ्टवेयर अब [कम से कम] दो टीसीपी पोर्ट, आउट-ऑफ-बैंड और ऑपरेटिंग सिस्टम के ज्ञान के बिना सुन रहा है। मान लीजिए कि मैं एक दूरस्थ होस्ट के लिए एक टीसीपी कनेक्शन शुरू करता हूं, और होस्ट स्टैक [बॉक्स के लिए वापस आने वाले पैकेट के लिए] सुनने के लिए स्थानीय पोर्ट के रूप में 16992 या 16993 चुनता है।

दूरस्थ मेजबान से लौटने वाले पैकेट को "ब्लैकहोल" नहीं मिलेगा और कभी ओएस तक नहीं पहुंचेगा? या क्या कुछ निवारक उपाय है, जैसे लिनक्स कर्नेल में एक इंटेल ड्राइवर यह जानते हुए कि टीसीपी को 16992 पोर्ट से बचना चाहिए? (लगता है कि यह एक OS-agnostic सुविधा है क्योंकि संभावना नहीं है।) या हो सकता है कि प्रबंधन इंटरफ़ेस 16992 पोर्ट पर भेजे गए ट्रैफ़िक को अग्रेषित कर सकता है जो होस्ट स्टैक पर वापस जाने वाले प्रबंधन सत्र से संबंधित नहीं है?

किसी भी तरह से, मैं नेटवर्क-गहन भार के लिए इसका उपयोग करने के लिए अनिच्छुक हूं जब तक कि मैं यह नहीं समझता कि यह कैसे काम करता है। मैंने Intel दस्तावेज़ीकरण की खोज की और वहाँ कुछ भी नहीं पाया।

मुझे लगता है कि यह लगभग 30,000 टीसीपी कनेक्शनों की शुरुआत करके परीक्षण किया जा सकता है, और अगर पोर्ट ओवरलैप होता है तो भी कनेक्टिविटी काम करती है या नहीं, इसकी जाँच करें। लेकिन मुझे अभी तक ऐसा करने का मौका नहीं मिला है।

(फुटनोट: मुझे इस सवाल का एहसास है कि इंटेल vPro आधारित कंप्यूटर IP कनेक्टिविटी को कैसे बनाए रखता है? लेकिन यह प्रश्न सामान्य तौर पर कनेक्टिविटी को संबोधित करता है, न कि विशिष्ट TCP पोर्ट से कनेक्टिविटी का जो होस्ट स्टैक से ओवरलैप होता है।)

Comments

मैंने देखा कि किसी ने इसे ऑफ-टॉपिक के रूप में बंद करने के लिए मतदान किया था। उस मामले में, मैं पूछना चाहता हूं: यह पेशेवर सर्वर प्रशासकों के लिए प्रासंगिक नहीं है ? यदि आप एक आउट-ऑफ-बैंड प्रबंधन तकनीक को सक्षम करने जा रहे हैं, तो क्या आप जानना नहीं चाहेंगे कि क्या आपके नेटवर्क संचार पर इसका प्रभाव पड़ेगा?

— mpontillo

मेरा अनुमान है कि यह उन बंदरगाहों पर सभी ट्रैफ़िक को देखता है, और अगर इसकी कोई चीज़ इसे नहीं पहचानती है तो यह इसे पास तक बढ़ा देता है। लेकिन यह पूरी तरह से अटकलें हैं।

— अनुदान

अच्छा प्रश्न। मैं सोच रहा हूं कि इस तरह की सुविधा के उचित कार्यान्वयन के लिए एक अलग मैक पते पर अपने स्वयं के आईपी स्टैक का उपयोग करना होगा ताकि संभावित संघर्षों से पूरी तरह से बचा जा सके। संघर्षों के परीक्षण के लिए आपको 30000 टीसीपी कनेक्शन की आवश्यकता नहीं है। इसके बजाय आप बस कुछ ऐसा करने की कोशिश कर सकते हैं nc -p 16992 example.com 22और देख सकते हैं कि क्या होता है।

— कास्परड

@kasperd धन्यवाद; मुझे नहीं पता था कि आप आसानी से ऐसा कर सकते हैं। मैं आगे बढ़ा और टेस्ट चला। AMT के लिए अच्छा नहीं लग रहा है ...

— MPontillo

Answer 1

एक साझा आईपी पते पर सुनने के लिए एएमटी को कॉन्फ़िगर करने के बाद, मैंने ऊपर की टिप्पणियों में कैस्पर द्वारा उल्लिखित परीक्षण चलाया । (एसएसएच सर्वर के साथ मेरे अपने रिमोट होस्ट के खिलाफ, वास्तव में नहीं example.com, निश्चित रूप से) यहां परिणाम है:

सकारात्मक परीक्षण मामला ( एएमटी द्वारा उपयोग नहीं किए गए पोर्ट का उपयोग करते हुए ):

$ nc -p 16991 example.com 22
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4
^C
$

नकारात्मक परीक्षण मामला (एएमटी द्वारा उपयोग किए जाने वाले पोर्ट का उपयोग करके):

$ nc -p 16992 example.com 22
$

(कुछ मिनटों के बाद, नकारात्मक परीक्षण का समय समाप्त हो गया और शेल प्रॉम्प्ट पर लौट आया।)

इसलिए जैसा कि आप देख सकते हैं, होस्ट के टीसीपी / आईपी स्टैक तक पहुंचने से पहले पैकेट को 16992 पोर्ट पर वापस आ गया था।

अनुशंसा: यदि विश्वसनीय नेटवर्किंग आपके लिए महत्वपूर्ण है, तो अपने होस्ट टीसीपी / आईपी स्टैक के समान एएमटी पते पर एएमटी को सक्षम न करें!

Answer 2

सुझाव के साथ होस्ट आईपी और इंटेल एएमटी डिवाइस आईपी के बीच इंटेल फोरम मैपिंग में एक विवादित धागा है

किसी को एएमटी के लिए अलग-अलग आईपी पते को कॉन्फ़िगर करना होगा और स्थिर आईपी के साथ संचालन करते समय होस्ट करना होगा।

और एक स्पष्टीकरण:

जब आप vPro मशीन को स्टेटिक आईपी के साथ कॉन्फ़िगर करते हैं, तो AMT मैक एड्रेसैबिलिटी मैक नामक मैक एड्रेस का उपयोग करेगा जो केवल स्टैटिक आईपी मोड में खेलने के लिए आता है। प्रबंधनीयता मैक पता होस्ट द्वारा प्रस्तुत मैक पते से अलग है।

मैं पुष्टि करता हूं कि एएमटी और होस्ट दोनों के साथ डीएचसीपी का उपयोग रूटिंग समस्याओं की ओर जाता है। उदाहरण पिंग गुमराह:

64 bytes from 192.168.1.11: icmp_seq=18 ttl=64 time=0.559 ms
64 bytes from 192.168.1.11: icmp_seq=18 ttl=255 time=0.614 ms (DUP!)
64 bytes from 192.168.1.11: icmp_seq=19 ttl=64 time=0.579 ms
64 bytes from 192.168.1.11: icmp_seq=19 ttl=255 time=0.630 ms (DUP!)
64 bytes from 192.168.1.11: icmp_seq=20 ttl=64 time=0.553 ms
64 bytes from 192.168.1.11: icmp_seq=20 ttl=255 time=0.602 ms (DUP!)

Answer 3

दूरस्थ होस्ट से लौटने वाले पैकेट को "ब्लैकहोल" नहीं मिलेगा और कभी ओएस तक नहीं पहुंचेगा?

"एएमटी-पोर्ट्स" के साथ रिमोट होस्ट के सभी पैकेट कभी भी किसी ओएस पर नहीं पहुंचते हैं। उन्हें Intel ME / AMT द्वारा इंटरसेप्ट किया गया है। डिफ़ॉल्ट रूप से वे 16992-16995, 5900 (AMT ver। 6+), 623, 664 पोर्ट हैं।

Answer 4

क्या ध्यान दिया जाना चाहिए, कि AMT का उद्देश्य ग्राहक OOBM तकनीक है जो सर्वर एक नहीं है। इसलिए हां, ऐसा हो सकता है कि आपका कंप्यूटर AMT पोर्ट का उपयोग करने का निर्णय ले, लेकिन केवल उस स्थिति में जब आपने विशेष रूप से ऐसा करने के लिए इसे कॉन्फ़िगर किया हो। अधिकांश OS प्री -ffured ephemeral पोर्ट्स के साथ 49152 से 65535 की रेंज में आते हैं, जैसा कि IANA विनिर्देश द्वारा सुझाया गया है, कुछ लिनक्स डिस्ट्रोस 32768 से 61000 और पुराने विंडोज 1025-5000 के साथ।

इसलिए मेरे दृष्टिकोण से यह एएमटी के लिए साझा आईपी का उपयोग करने के लिए बचा है क्योंकि इसके पोर्ट्स अल्पकालिक सीमा में नहीं हैं (जब तक कि आपको पता नहीं है कि आप क्या करते हैं, और इस विशेष सेटिंग को बदलते हैं) और किसी भी एप्लिकेशन द्वारा सुनने वाले पोर्ट के रूप में उपयोग नहीं किया जाना चाहिए।

Answer 5

एक समाधान का उपयोग करके Windows TCP स्टैक के लिए पोर्ट सेट करना हो सकता है netsh।

डिफ़ॉल्ट रूप से, विंडोज 49152 >> 65636 (या जो कुछ भी ऊपरी है) पोर्ट का उपयोग करता है, इसलिए आप एएमटी का उपयोग करने के लिए बहुत सुरक्षित हैं। आप पोर्ट रेंज के साथ सेट कर सकते हैं netsh। उदाहरण के लिए, मैं हमेशा परिधि मशीनों के लिए लगभग 1000 बंदरगाहों का उपयोग करता हूं।

इसके अलावा, इंटेल एएमटी आदेशों को बंद कर देता है और उन बंदरगाहों पर अन्य सभी ट्रैफ़िक (16991-16995 वास्तव में!) को ओएस पर भेजता है (यदि कोई ओएस मौजूद है)। इसलिए यदि आपके पास एक एप्लिकेशन होगा जो एएमटी रेंज में एक पोर्ट खोलेगा, तो ट्रैफिक ओएस के माध्यम से आवेदन के लिए अभी भी पास होगा, क्योंकि जैसे मैंने कहा था, इंटेल एएमटी प्रबंधन कमांड के केवल स्ट्रिप्स हैं। इसकी संभावना नहीं है कि आपका एप्लिकेशन AMT कमांड भेज रहा है।

Comments

यह उत्तर मानता है (1) आप विंडोज का उपयोग कर रहे हैं, और (2) आप किसी ऐसे सॉफ़्टवेयर का उपयोग नहीं कर रहे हैं जो अन्य कारणों से एएमटी-ओवरलैपिंग पोर्ट का उपयोग करने का प्रयास कर सकता है। (आप उदाहरण के लिए, एक वीओआईपी एप्लिकेशन जो यादृच्छिक यूडीपी पोर्ट का उपयोग करते हैं) हो सकता है कि यह इस बारे में भी दावा करता है कि कैसे इंटेल एएमटी कमांडों को "स्ट्रिप्स" करता है, जो स्पष्ट रूप से मेरे उत्तर में गलत दिखाया गया था। क्या आप अपने दावे का समर्थन करने के लिए एक संदर्भ प्रदान कर सकते हैं? मुझे आश्चर्य नहीं होगा अगर इंटेल ने इसे एक बग माना है और इसे एक दिन तय किया है, लेकिन जिस समय मैंने अपना जवाब पोस्ट किया, वे स्पष्ट रूप से नहीं थे।

— एमपॉन्टिलो